Bertrand Le Roy
Bertrand.Le.Roy at microsoft.com
Fri Sep 26 13:12:50 PDT 2008
Apologies for the extreme lateness...
IDE Minutes 2008-09-09
Jump to: navigation<http://www.openajax.org/member/wiki/IDE_Minutes_2008-09-09#column-one>, search<http://www.openajax.org/member/wiki/IDE_Minutes_2008-09-09#searchInput>
Jon: Multiple returns: Lori made proposal, fine by Bertrand. What do people think?
conditional could be useful too. On the other hand it means getting into evaluating expressions.
Jon: I've been trying to go beyond just options. Also works with type=String.
Lori: but you have to know what the values are.
you're just enumerating differently.
Jon: thought about having syntax for both parameter name and param value. Then you don't need the parentheses. Example has parameter, equals and value. We could have parameter key and value and express that in a more simple way.
Jon: you guys are apparently not seeing additional value in my proposal.
your proposal has more potential and is more flexible. On the fence.
Lori agrees, especially as this is pseudo-JS, not JS.
Jon: what about Bertrand's case? You could have param id on the returns element. Lori, are you ok with me going ahead with the proposal?
Jon: if the value is a function, how do you know the type?
Bertrand: a = new Foo should behave the same as a = create(Foo)
Jon: should put a warning that if you provide a function as the parameter, some tooling environments might not be able to figure it out. Web based ide might be more difficult.
Bertrand: Actually I think the reverse is true.
Jon: let's move on. String or function specifies param. How do we differentiate? The param has its own type; if the paramid is on the param itself, then the parameter value is being used. If on option, it's the option value.
B: sounds good.
Lori: what does the return type look like?
Jon: like in your proposal: paramid=xyz on returns and paramid=xyz on the param or option.
Lori: what happens to dataType in this case?
Bertrand: or not specify
Lori: better not to specify dataType in this case. Actually, Bertrand's original proposal to say dataType="classname" for example works better.
Bertrand: addressed the problem of conflicting param names and type names in original proposal by having parameter names take precedence over more global type names.
Lori: one more idea, maybe confusing. Not loving paramId, so how about returns paramId=classname/db?
Bertrand: maybe use name on options?
Jon: get rid of prarmId on option./ On returns, paramName and paramValue. If you don't use them you can use dataType. Returns paramname=classname paramvalue=beta.database datatype=Database.
Bertrand: in generic case?
Jon: it's still the initial returns dataType=classname.
Kin: How about using @?
Lori: worried about overloading @.
Jon: could go either way.
Bertrand: maybe less ambiguous with @ but still slight preference for no @.
Let's make sure this is made clear in the spec.
[PicExportError] Kin: How is a non-mashable widget described?
[PicExportError] Jon: if not mashable don't inject all that stuff.
[PicExportError] Javier: what do we mean by mashable?
[PicExportError] Jon: Yes. Mashable means they can talk to each other, can change dimensions, etc.
[PicExportError] Javier: one of the properties says it has publish/subscribe, isn't that enough?
[PicExportError] Jon: what about the dimension stuff?
[PicExportError] Javier: right.
[PicExportError] Jon: those are the big items but whether you invoke the API is the best criterion.
[PicExportError] properties make sense in the IDE even if you don't call the api.
[PicExportError] Kin: assumption that ide is going to provide this extra code to make it work.
[PicExportError] Jon: we provide openajax.js already so we could also provide this minimal implementation file.
[PicExportError] Kin: who's supposed to provide implementation?
[PicExportError] Jon: ultimately ide is going to inject the code into the page but we could provide shared implementation from OpenAjax. Some things are easy to share, like pub/sub, but things like dimensions will be ide specific.
[PicExportError] Kin: DreamWeaver won't be able to consume that.
[PicExportError] Jon: which parts?
[PicExportError] Kin: parts that aren't in the page.
[PicExportError] Jon: the minimum implementation wouldn't have dimensions, property getting and setting except for pub/sub stuff. Highly recommended would be pub/sub, load and unload events. For those we could provide code. A widget has to surrender communication for security reasons to the container, so there's no way to get everything packaged in one place. The host environment gives the hooks to communicate.
[PicExportError] Kin: where is it creating that?
[PicExportError] Jon: the ide has to insert that line of code into the page, which will cause it to be mashable.
[PicExportError] Ken: seems like the whole thing is geared at runtime communication.
[PicExportError] Lori: audience in DW is not going to understand pub/sub. Need to make it easier to understand for the designers.
[PicExportError] Jon: how does the DW dev specify that something should be triggered by something else?
[PicExportError] Ken: they have callbacks, they can understand callbacks.
[PicExportError] Jon: if you're going to have only one widget for both scenarios (mashable or not), that's the price to pay, but you don't have to use that stuff or understand it if you don't need it. Developers will have to check for APIs before using them though.
[PicExportError] Ken: I'll try to come up with a proposal.
[PicExportError] Jon: I don't think it will take too much work to make this work in DW but waiting for your feedback. Just good practice to check if stuff exists (such as wrapper) before using it. OK to put burden on widget author.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 50 bytes
Url : http://openajax.org/pipermail/ide/attachments/20080926/17954f8b/attachment-0003.gif
More information about the IDE