IDE Minutes 2008-08-12

From MemberWiki

Jump to: navigation, search




  • Lori Hylan-Cho, Aptana
  • Bertrand Le Roy, Microsoft
  • Wayne Vicknair, IBM
  • Kin Blas, Adobe
  • Phil Berkland, IBM
  • Ted Thibodeau, OpenLink
  • Kevin Hakman, Aptana
  • Jon Ferraiolo, IBM


(going through recent email discussion)

"Multiselect properties - must have datatype of array"

Most recent proposals: (a) @operator="|| && ..." (b) multiple=true&datatype=Number => bit OR'ing, (c) Aaron's more general notion of addition, where strings can be concatenated.

summary of email chatter, no significant discussion...

APPROVED without objection -- (c) Aaron's more general notion of addition, where strings can be concatenated.

"Inline, macro-expanded content within <requires> element"

Most recent proposal: keep <preload> and <postload>, add <javascript> as child of <requires>

summary of email chatter...

Kin -- validator doesn't understand all markup, as things stand. things <requires> should be an empty element

Wayne? -- why do we have five ways to include javascript?

  • preload
  • postload
  • inline require
  • javascript
  • (I missed one --Ted)

Kin -- we had no way to insert JS into HEAD, that's what PRE and POSTload do, so brought them back, which makes REQUIRE a non- empty element *or* forces use of an external file...

Wayne? -- still don't see why this is needed ... why other changes broke existing usage

Jon -- other options are basically ugly.

Agreed to keep spec as is, keeping <preload> and <postload> and inline content for <require type="javascript"> and <require type="css">. The approved change is to allow macro substitution on <preload> and <postload> and inline content for <require type="javascript"> and <require type="css">

shifting to Kin's latest email questions...

Kin -- 1. How should script within the <requirements> section be interpreted by an IDE? Should there be an instance of this script *per* widget instance in the page? Or is this expected to be a singleton instance within the page?

Jon -- if each widget goes in iFrame, each gets its own copy of script; if they go in same iFrame, then they're sharing... wait until there's an example to expose a problem.

Kin -- 2. Are IDE's expected to do a pure content replacement of @@place-holders without regard to type? For example if a property is of type "string", should the templated code/markup provide the quotes around the place holder? Example: var foo = new Foo("@@name@@"); Š I'm guessing this is the case, but what is the ide supposed to do if the replacement text contains quotes?

Jon -- potential cross-site scripting vulnerability, among other aspects to this question... previous thought was just to warn tools that "they should be careful". JS has lots of issues with quoting problems, just dying without alert or warning...

Kin -- 3. Do we need to add an additional format for "string" that allows an IDE to figure out whether or not it should entity encode a string prior to doing the macro replacement? The Scenario I'm thinking about is something like this: <div>@@description@@</div>

Kin & Jon -- 2 & 3 are tied together ... might need to add something that hints to IDE whether a variable value needs to be escaped or cater for quotes or such.

seems there needs to be *something* available to handle entity encoding and quotation-mark escape issues....

Jon to write up proposal.

"@default for various data types"

(Most recent proposal: @datatype=String|Date => treat default as string or date; otherwise, treat as JS expression)

Jon summarizes ...

Kin -- why wouldn't DATE be a format? can be expressed in milliseconds, right?

Jon -- thinking date is anything that can be parsed by date.parse

APPROVED without objection


(Rich's proposal: allow message bundles inline within widget metadata file)

Jon summarizes ...

Tentatively APPROVED without objection, but Jon will start email discussion to discuss details

Personal tools