IDE Minutes 2008 07 15

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2008_07_15

Contents

Attendees

  • Javier Pedemonte, IBM
  • Lori Hylan-Cho, Adobe
  • Bertrand Le Roy, Microsoft
  • Phil Berkland, IBM
  • Jon Ferraiolo, IBM

Original agenda

  1. InteropFest:
  2. Lori's email: datatype="string" format="id"
  3. Lori's email: require src
  4. Lori's email: loading libraries
  5. Phil's email: proposal for widget child properties
  6. Phil's email (and Jon's response): OpenAjax API Metadata spec problems

Minutes

InteropFest

jon: interopfest discussion

jon: proposing to use IBM's mashup as scaffolding for interopfest

jon: test library would be test for IDEs

jon: refimpl mashup needs some usability improvements

jon: idea would be that users could upload widget, drag onto canvas, and test with a different validator widget. reports events that uploaded widget publishes/subscribes

jon: for JS lib, there would be a library tester widget, would evaluate library for proper metadata

lori(?): for IDEs, how do we get widget spec file?

jon: i'll develop sample JS library, which IDE will load

phil: what's the privacy for uploading?

phil: give option of making it public or not

phil: download what others have uploaded

jon: we'll have to think about that

jon: we might have to come up with a different solution for those who want their data to stay private

Lori's email: datatype="string" format="id"

jon: next topic: lori's email on datatype="string" format="id"

jon: format attribute that tools might do something special with

jon: lori suggests adding "id" type for 'format' attr

jon: i support adding this. anyone object

[ no objections ]

Lori's email: require src

jon: next is 'require src'

jon: when we have a CSS asset, asset can reference a file, or can be a snippet

jon: lori wants to know why shouldn't we do this also for 'javascript'

jon: does anyone have concerns?

[ no concerns ]

Lori's email: loading libraries

jon: next is 'loading libraries'

jon: question is 2 different widgets refer to a file dom.js

jon: what if there are multiple dom.js files, perhaps provided by 2 different toolkits

jon: how should this be handled?

jon: i assume it should be possible for tool to determine whether requested file is within a certain distribution, because dom.js will have the same directory structure

lori: that's one case, where you download a whole JS toolkit, and there are several components within

lori: but there is the other case where a developer will write a standalone component, outside of a JS toolkit

lori: if the requested asset is not with a JS toolkit structure, how do you tell?

lori: makes sense to share a given toolkit amongst many widgets

jon: i propose we take this to email and try to come up with a proposal

jon: maybe we need to resurrect the 'shared' attribute

jon: on to phil's emails

Phil's email: proposal for widget child properties

jon: proposal for widget child properties

jon: example -- a vertical layout widget that will align its children vertically

jon: then there would be widget properties on the main widget, but it could also specify child properties that would be put attributed to any child widgets it contains

jon: not sure whether 'property' is the right term to use here

jon: maybe should be called 'child attributes'

phil: yeah, name could be changed

jon: how many toolkits do this with markup vs javascript?

jon: seems like we should do some research on this

jon: let's tentatively change it to "child attributes" and see how various toolkits deal with this

phil: sounds fine

jon: i'll do the research

jon: bertrand, what about microsoft toolkit?

bertrand: i don't think that affects us

Phil's email (and Jon's response): OpenAjax API Metadata spec problems

jon: next, phil's email about metadata spec problems

jon: phil pointed out that 'descriptive_elements wasn't defined.

jon: i updated the schema

phil: related problem where there could be an 'author' tag on many method, field,...

jon: i didn't include 'author'

phil: that may mean we'll need to explicitly add 'author' in a few places

jon: ok, let's both take a look, see if anything is missing

jon: 2nd, 'ancestor' element not referenced by anything

jon: it is referenced by 'class'

jon: does 'ancestor' make sense for 'mix, 'mixin', 'namespace'

jon: doesn't make sense for 'namespace' or 'mix'

jon: does it make sense for 'mixin'?

jon: 'mixin' could refer to a parent class

jon: i'll send email to ingo (?) and see if he has any thoughts on this

jon: 3rd, 'alias' tag should be child of the 'api' tag?

jon: 4th, should 'event' be contained by 'class'

jon: yes

jon: 5th should 'constructor' tag have 'scope' attr?

phil: does it make sense to have a static constructor?

jon: so remove it?

phil: yes

jon: 6th, 'exception' element used to have a datatype, should it?

jon: datatype of the exception object?

phil: yes, i think so

phil: 'returns' was added to spec

jon: yes, my assumption is that 'returns' is the datatype

jon: i think this is another question for ingo (?)

jon: 7th, i'll fix 'field_elements'

jon: anything else for this week?

phil: what's the difference between a 'field' and a 'property'

jon: a 'property' is something that is managed, but a 'field' you can call directly

jon: have to call getter/setter for 'property'

Personal tools