IDE Minutes 2008 10-07

From MemberWiki

Jump to: navigation, search




  • Bertrand, Microsoft
  • Jon, IBM
  • Kin, Adobe
  • Lori, Aptana
  • Stew, IBM


Mashable Widgets

Jon: One could argue that we want a couple of mashable widgets. We could say ide's need to provide the scaffolding

Jon: Or we can make it so it is easy for widget developers.

Stew: In the IDE scenario I envision 2 models

Stew: I always thought there were a set of ides that render in a design mode. And other ides that have placeholders for the visuals and manipulate the properties, and generate code.

Jon: Can widgets optionally opt into the apis

Stew: APIs allow you to integrate with other widgets in the document. I'm of the mind that I would make it optional.

Jon: Yeah, that's what Kin and I were feeling.

Jon: My feeling is DW CS4 is a major product in the industry which isn't supporting the mashable format. We might as well go along and rally around the first major product that is shipping.

Lori: This doesn't effect Aptana as much as it does DW.

Lori: Not really worried about widgets at the moment.

Jon: Those mashable apis would be optional. You as an IDE don't have to provide scaffolding.

Kin: That's what I was mentioning I wanted to look into. The OAA providing some JS file that a widget writer could include that automatically did all the checking for the availaiblity of the mashup environment.

Jon: I'm pretty sure that can be done.

Change the Default for the 'src' attribute on <require>

Jon: Only response was from Rich Thompson that said he thought it was reasonable.

Jon: Talked to Lori at AJAX Experience and javier, and Now I'm backing off.

Jon: Dojo library is used in our reference implementation. We don't want multiple Dojo's coming down with each widget.

Jon: Lori pointed out if you just point to an absolute URL things should just work out. If you want to use Dojo, Prototype, Dojo, etc then you can just point to the CDN on AOL, Google, or on your own website.

Jon: Long story short is "nevermind".

Kin: The implementation we have assumes that if an oam.xml file is loaded from an absolute URL, and if the <require> paths are relative, we copy the files locally. If the <require> paths are absolute URLs, then we only insert references to them without ever copying them locally.

Jon: The most specific spec change would be to clarify that if you are pointing to an asset with an absolute URL, then you should just preserve that.

Kin: Right.

Jon: One more thing to clarify after talking to Javier, it is ok for the tool to put a cached/local copy of the toolkit even if there is an absolute URL. One of the benefits of relocation is that you can have a local copy. Especially if your app already have a local copy of dojo.

Jon: If you use the library feature the ajax libraries are relocateable. The target attribute does not apply when using the library attribute, but it does apply everywhere else. If you are not using the type="library" or library="" attribute then target is allowed.

Jon: Comes back to kin's question about what if the src of the require is an absolute URL and target is specified. Then the IDE would have to copy.

Kin: Right.

Dojo Feedback

Lori: I talked to Kevin, its kind of sad that we went with class model approach. But it makes it easier for tools.

Jon: Yeah I sent comments to ??? Visual Studio and Eclipse are 2 major IDEs that use class based tooling.

Jon: Lets see what the Dojo guys come up with.

Jon: We may consider a prototype way of expressing JS based APIs and also support the class based approach. JSDoc uses class based.

Jon: Minimize the lossiness of how you express your apis is good. You don't want to force lossiness, but that is preliminary to see what Dojo comes up with.

Lori: Yeah I want to see what they come up with too. The code assist file they gave us contained no mixin tags. We invented the mixin tags for them, but they didn't use it.

Jon: Maybe what you got was a flattened version.

Kin: What is a mixin?

Lori: Different objects inherit some methods.

Bertrand: A set of members are dynamically copied

Lori: They are added through run-time.

Jon: Piecemeal cloning of properties. Because JS is a dynamic language you can do that. In JS you can say I want to grab properties A, C, and E from this object because I like those.

Bertrand: Not including higher level constructs would be a mistake. The real test would be expressing major frameworks like jQuery.

Lori: Yeah, right now we add asdoc[??] comments

Bertrand: Actually they have JSDoc in their tree.

Jon: Bertrand, I see your point. There's metadata you can put in your source code which will make your source more useful in an IDE. We shouldn't cut out that level of meta-data. We're the ide working group that's what we're here for.

Options Object Literal

Lori: I just emailed about this topic to layout the problem.

Lori: There isn't a way of saying this property corresponds to an options object passed to a constructor.

Jon: In your example you have an optoin named draggable. Would that only appear in that one parameter?

Lori: Yes

That would implicity appear in a properties dialog?

Lori: Yes

Lori: If you wanted to say

Jon: properties that appeared in the constructor would be appended to

Lori: I'm not thinking about UI. I'm just talking about a way to pass an options object

Jon: What's the tie in between the class element and the widget element.

Lori: One is API data. I was just describing my widget as part the api, so that if the user were typing they would get hints.

Lori: If someone was inserting this panel in Dreamweaver and they choose that they don't want their panels to be draggable.

Kin: Lori is trying to describe the scenario where the constructor takes an optional object for changing the widget defaults. In some toolkits, like jQuery UI, just the presence of an object with a specific property is enough to change the default for that property.

Lori: Yes.

Jon: Here's my question. how does the tool know that this widget below has any relation to the class above?

Lori: those 2 things are spearate. The top one is for coding (API meta data) for code hinting. We already have this mechanismi in the api metadata. but for the widget data there isn't a way to automatically

Jon: What in the meta data says this optional property is tied to where it should be inserted, etc.

Lori: That's my point. There is nothing that exists within the widget meta data.


Lori: When I originall proposed this for Adobe, it assumed there was a constructor and it looked more like an API metadata, but we (OAA) moved away from that towards properties and there isn't anything to express this.

Lori: We don't have a way to say this is an argument that goes here.

Jon: Oh so you're not defining a solution.

Lori: I just wanted folks to understand the problem.

Jon: We could invent a syntax that a special thing a tool needs to do a substitution where you insert an object literal or nothing depending on whether any properties are different from their defaults. We already have that notion that when it invokes a constructor that it should only pass the non-default options. The only problem is the comma.

Jon: we could put in a note in the spec that the widget developer needs to check that the library won't die in the case when there is no optoins object and we pass undefined in its place. Just in case they were assuming that the argument count indicates the presence of an options object argument.

Lori: I want to be able to mark the properties that should go in this options object.

Jon: We already use __OPTIONS__ convention. It's already a special thing.

Lori: What do we want to use (in meta data) that tells the IDE that this is an optional constructor property.

Jon: An obvious thing to do is add another attribute like constructor="true".

Lori: Right it could be anything.

Jon: which is the common case? To pass it, or not to pass it.

Lori: False I would think.

Kin: Right.

Jon: If constructor option is false. Then that property is not put in the object literal. It gets put into the object literal if its value isa non-default value and the constructor attribute is true.

Lori: Kin is proposing instead of having a constructor option true, that there be a property named options and it should have children enumerating the properties of that element. Which is also fine by me.

Kin: We should put this in an email so we are all on the same page.

Personal tools