IDE Minutes 2008 06 24

From MemberWiki

Jump to: navigation, search

Attendees

  • Jon Ferraiolo, IBM
  • Lori Hylan-Cho, Adobe
  • Rich Thompson, IBM
  • Ted Thibodeau, OpenLink
  • Stew Nickolas, IBM
  • Bertrand Le Roy, Microsoft, scribe

Minutes

Jon: got a formal schema, validation, extraction tool to get parts of the schema into spec, etc. Did a full pass on specs. Compared Aptana’s spec against ours. We’re in really good shape. Not a good story on localization though. Let’s talk about it next week. Need to do cleanup and research. Let’s go through red items in widgets. Issue whether the name attribute needs to be restricted. Conclusion was that JS identifiers are ok. It’s optional, but you really should have one. Tools can make their own decision. …No objections…

Width and height: what about if they’re not specified? No defaults, the tool deals with it and makes a decision. … no objection…

PreserveAspect attribute: this disappeared from Google gadgets, so the proposal is to remove this as well. … no objection…

Directory title and singleton: Stew describes the proposal. Overlap with the sandbox attribute, Jon will include that but both are needed. Sandbox is on widget, singleton is on content. … agreement …

Next red item is in content: CDATA doesn’t work in the case where you want to include @@ in a description for example. Might be able to use entities. The red comment about escaping can be removed. .. agreement…

Localization: what can be localized, what can use @@foo@@? The transformation should be applied to all those elements (listed in the red comment) … agreement…

Src attribute only makes sense for urls. Does anybody need to reference metadata files with relative url? Lori points out this should work with type. If the types are html and url, do we need src to do the same thing? We previsouly thought if src is there then it’s url.

Jon: when you say type=url, it’s a full document, whereas if html it’s a fragment. Either say if you put src it’s type url or we allow type html and src that points to a fragment.

Bertrand: would have expected fragment and document, something more expressive than url and html.

Rich: Even among us, we are understanding different things with url.

Jon: let’s have fragment or page for type, src for a url in both cases.

Lori: any other cases?

Rich: default is fragment

Jon: type is fragment or page, default is fragment, src attribute will work with both, and if not present we use the contents of the node.

Rich: there is no or in the next paragraph.

Jon: either instead. And a comma.

Rich: what if there is both contents and src. Who wins? Lori agrees.

Jon: we talked about that, if src is there, it wins.

View attribute: Does anybody object (Google gadgets supports that)? … silence…

Next is on require element: Lori’s question. Jon proposes that we remove this.

Lori: had a discussion with implementers, still not convinced but they’re asking if there’s a way to share a file across widgets?

Jon: thought about this and assumption is that the tool can manage that.

Rich: using metadata?

Jon: management nightmare?

Lori: not sure we have a great way of doing that. Site-relative against document-relative. Proposes target attribute that says where it goes once the widget is on the page. Do we have some standard way of expressing that target? Copying the files that you need to the site, so part of the question is what happens if you have multiple instances on multiple pages, is everything copied multiple times? We have a central place where we have all the pieces and copy what you need for each widget to the site.

Rich: everything widget relative, not site-relative.

Lori: makes no sense for developer scenarios.

Stew: or from widget.

Lori: some way of specifying if something needs to be copied or referenced. Still struggling with why we would need both. Seems like the person inserting the widget should decide.

Jon: widget is self-contained and resources are self-contained and you might share across pages then you might see that a widget is shared and puts it into shared area. New instances would point to the shared one.

Lori: that was my suggestion, they (devs) didn’t like it, wanted the widget developer to decide, but how would he know, the site dev should make that decision?

Jon: re-discuss next week.

XSL: will anyone use it?

Lori: no.

Jon: what if someone needs it? Could always not support. Would be inclined to drop it.

Bertrand: let’s not keep it just in case.

Jon: widgets api. Proposal from the gadget tf. Explains the proposal. Anybody see problems? … silence …

Rich: get and set property values have the same description.

Stew: will fix.

Jon: insert type in customized edit mode.

Lori: don’t think that’s absolutely necessary.

Rich: do you have an event when something is added to the page?

Lori: we have an api for callbacks at design time.

Jon: dropping the insert mode?

Lori: using custom namespaced attribute. If anyone else needs it that’s cool. dataview:extensiontype=command|pi(property inspector)|panel|object in DreamWeaver.

Jon: want to add whatever would be useful to other environments.

Lori: sure.

Rich: nothing to tell a widget to be in edit mode when inserted.

Jon: api to request/change designer mode.

Lori: we assume that all have an edit view.

Jon: what about add and remove events?

Rich: load and add are different.

Jon: right, if several instances are added, right?

Rich: no, load is delivered to each instance when page loads. Add occurs when instance is first added to the page.

Jon: Stew should come up with a new writeup that we’ll discuss next week.

Personal tools