IDE Minutes 2009 09 01
From MemberWiki
URL: http://www.openajax.org/member/wiki/IDE_Minutes_2009_09_01
Contents |
Attendees
- Jon Ferraiolo, IBM
- Lori Hylan-Cho
- Javier Pedemonte, IBM
- Kin Blas, Adobe
Minutes
REQUIRE type=inline
Lori: Seems like it should be more specific. Seems too general. You already have different require types that are inline. How about require type=comment.
Kin: But it may include script, style, or conditional comments
Lori: Maybe type=generic
Kin: type=markup
Javier: This would duplicate stuff we already have. It is making inline js and css more general.
Lori: type=markup is probably the best
RESOLUTION: Add REQUIRE type=markup
'type' and 'includeRef' on LIBRARY
Kin: If type not provided, then defaults to 'folder'
Jon: I liked Kin's proposal. Gets rid of the need to require a trailing slash on 'src'
Javier: I'm worried about duplicated REQUIRE. Why not just add a 'library' attribute to REQUIRE
Jon/Kin: (discuss why this approach is good and why we are leveraging LIBRARY for relative URLs and how earlier discussion we decided we liked containment for semantic reasons)
RESOLUTION: Add 'type' to LIBRARY. Defaults to 'folder'.
Lori: Why add 'includeRef'
Kin: You may be pulling it in programmatically. Not likely today, but could be possible.
Lori: That's why we took it out. Couldn't come up with a real-world example. If we put it into spec, need to put in a description of the use case.
RESOLUTION: Restore 'includeRef' on LIBRARY but include a note in spec that describes why it is there.
API Metadata chapter
Lori: Part way through. I fixed some minor editing things. One question: which elements does ALIAS apply to?
(discussion of singleton, interface, mixin. then discussion of method and property)
Jon: Doesn't make sense to interface and mixin because they are only referenced. For method and property, unlikely to be used. If we put it in the spec, probably wouldn't be implemented because it would be some work and unlikely to see content with it.
RESOLUTION: Alias only for class and singleton.
(then discussion of returnType for constructor)
Jon: I think we made a mistake earlier. Because JS is general, and anything could be returned from a constructor, we decided to require a returnType for completeness. But 99% of the time the constructor returns an instance of the class. We should redefine it so that if no returnType then defaults to instance of class.
RESOLUTION: Default returntype for constructor is instance of a class
Lori will fix the spec.
Next week
continue API Metadata chapter
