IDE Minutes 2008-01-03
From MemberWiki
URL: http://www.openajax.org/member/wiki/IDE_Minutes_2008-01-03
Attendees this week
- Jon Ferraiolo <jferrai(at)us.ibm.com>
- Lori Hylan-Cho <lorihc(at)adobe.com>
- Kevin Hakman <khakman(at)tibco.com>
- Phil Berkland <berkland(at)us.ibm.com>
- Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
Minutes
Jon: Issue #5 is about how we describe constructing the widgets. Typical process, you have a div with an ID, then markup is replaced for that div and some js that gets executed for the constructor for that widget … so how do we represent
- the constructor
- the markup for that snippet
- and the other in which that should happen
...but we need others on the call to discuss this.: Stew (Gadgets TF), Greg Murray (Sun)
...<content> element can include markup and can include script...
...in wiki there’s examples of this … how google gadgets works registering an onload handler. Second one is registering some XML that holds the constructor <constructor> tag; what dojo does is script type="foo" then executes those manually based on the custom type.
..."tools" we're targeting is Ajax IDEs and Mashup Editors.
Tool will insert into the HTML page something that will execute at runtime.
Lori: part of the reasons that w have 2 separate areas for the HTML template and the constructor. HTML snippet is in body, then constructor at the end of the body. Theoretically they could be in same block, but the constructor MUST still come after the snippet.
Jon: usually 3 components:
a) some HTML – snippet of code b) a utility function -- c) some JS that needs to be executed
...could be permutations of the above.
Lori: anything that's 100% js will not be highly compatible with WYSIWYG tool like DW, but DW does not execute JS at authortime.
Bertrand: if in general you have a block for the widget and another block at the end of the body…in the second block at the end of the body, you can handle many cases. Or even in-line code that instantiates the code. It should pretty much work with any toolkit.
Kevin: it seems that could provide a fallback position
Bertrand: that scheme can handle the general cases, it seems that as a baseline would not require implementing against the arbitrary styles.
Jon: can we put javascript immediately after the block, or after the body?
Bertrand: if you insert everything in line, boot-strapping may not be ready yet
Jon: other option: some magic attribute: suppose markup tag, logic tag, then attribute for "goes before" goes after.
Lori: our proposal is for an attribute to declare where the code should go "afterHTMLsnippet" or "endOfBody"
Bertrand: this is relatively close to what's MSFT is doing for the server-side controls; we do not have this on client-side yet, but it's the same concepts. Today our designer's it's easier to work with XML markup…manipulating scripts is not the easiest thing, but the markup part that's all goodness.
Kevin: Action items for this
Jon: Let's look at Issue #3...localization
It's about localizing widget data itself, (not the widget).
For example: an enumeration would be custom text
Then the description fields would need to be localized:
Bertrand: Use existing format to id what is the schema is localizable and what's not.
MSFT solved this problem by having 2 separate files… what's localizable is
a) raw metadata, with all objects in metadata file have and ID b) Local language file with name value, name=id; value = text that goes there.
It’s simple for the person that’s localizing... one big file with string.
However MSFT’s schema is an element for each concept… not just attributes.
Phil: Eclipse ATF in Java does something similar to what the MSFT approach is… a separate file of name/value pairs, that matches the key in the master file.
Jon: how are the files named?
Phil: standard "_en" type conventions where in foo_en.xml name value pairs of keys and strings correlates to foo.xml
Kevin: I like the simplicity. It's a model that we use in TIBCO General Interface too.
Jon: who will consume these property files? Answer: IDEs and Mashup Editors
Jon: Are we OK with plain text of name value pairs
Kevin: What should the delimiter be?
Jon: Keys are only alpha-numeric therefore we can use : or = as the delimiter
Phil: We should define the keys, but it should support the extensibility notion as well.
Jon: If the original description is English, and if there's a supplemental descript properties file for French, then if the French locale is chosen, the French values are used.
Kevin: We're at the end of our hour. Next meeting, same time in 1 week.
