is there some way of making these components "render-only" like eelco (i think) wanted (so they're not in the component tree and thus the session)?
also, what if a <wicket:component> is named? should we allow that or not? if so, the user will want to look it up in java and set properties on it. i'm wondering if that's good or not...
Jonathan Locke wrote:
one seriously ugly problem we missed...
the <wicket:component> tag just specifies the class and any parameters in the immutable markup stream (probably as a subclass of ComponentTag like ComponentClassTag or CustomComponentTag).
but the question of how to instantiate "presentation components" like this is very tricky. since a page's constructor adds all its components, how do we know when to instantiate automatic components? this is especially tricky if the thing is a container. for example, if we have a simple page like this:
<wicket:component class = "roundedBorder"> <tag id = "wicket-whatever"> </wicket:component>
where the wicket-whatever component is added in java-land, how does the "wicket-whatever" tag get added to the "roundedBorder" container rather than the page container? it seems like add() might have to have some tricky logic in it for this case. it would have to look at the container its adding to and figure out from the markup stream if there is an intervening presentation component and wire that component in between somehow...
or is there some better solution?
Jonathan Locke wrote:
i'm just going to do this in narrative form in terms of how to change what...
first, we should change all occurrences of "wcn" to "wicket" per our earlier vote on this topic
<tag id = "wcn-foo">
becomes
<tag id = "wicket-foo">
then we also want to remove all special parsing of square bracket syntax and restrict wicket component names to legal javascript names beginning with componentName followed by a hyphen (by default this would be "wicket-"). if a tag has an id beginning with "wicket-" that is not a valid javascript variable name, we should throw a render exception saying that the component name is not valid and giving the valid characters in the exception message.
<tag id = "wicket-[whatever]">
is no longer valid and throws a render exception
this is good even though it will break what little wicket code exists so far because this will mean ids are being used in the way envisioned by the html spec.
next, we want to change the tag parsing so that any tag with a wicket component name can have a <wicket:params> tag following it that will set attributes on that component tag. the <wicket:params> tag MUST immediately follow the component tag and any optional whitespace. a <wicket:params> tag that does not immediately follow a component tag is not valid and should cause a render exception. a <wicket:params> tag MUST be OPENCLOSE (<wicket:params/>) or a render exception is thrown.
<tag id = "wicket-foo"> <wicket:params param1 = "value1"/> is valid and the same as
<tag id = "wicket-foo" param1 = "value1">
the same goes for openclose tags, btw:
<tag id = "wicket-foo"/> <wicket:params param1 = "value1"/>
is also valid and the same as
<tag id = "wicket-foo" param1 = "value1"/>
finally, this is NOT valid and causes a rendering exception:
<tag id = "wicket-foo"> whatever <b>tag</b> or text <wicket:params param1 = "value1"/>
next, since the square bracket syntax is gone, some tags in the wicket XHTML namespace will be used to represent those special markers. in addition we will add a new tag for creating components.
[autolink] vanishes entirely due to automatic behavior in examining anchor links (if a class can be found at the destination, the tag is marked as an autolink and assigned a link component). the functionality is exactly the same as [autolink] now.
[border] and [body] <span> tags become <wicket:region name = "border"> and <wicket:marker name = "body"/>
[panel] tags become <wicket:region name = "panel">
[remove] tags become <wicket:region name = "remove">
and to support parameterized "presentation components", we add a custom-component instantiating tag
<wicket:component name = "componentName" class = "classname" param1 = "value1"/>
this allows instantiation of a custom component, where classname is the class to instantiate and params are set on the resulting component as beans properties
for example:
<wicket:component name = "myRoundedBorder" class = "com.whatever.RoundedBorder" color = "0xff0000">
would instantiate a RoundedBorder object, set the color property on it (conversions should probably be aided by the conversions in the StringValue class. i may have some beansy property code somewhere that can help if this is a hassle) and give it the name "myRoundedBorder". if the name is omitted, a programmatic name will be generated. so
<wicket:component class = "com.whatever.RoundedBorder" color = "0xff0000">
is the same as
<wicket:component name = "anonymous-0" class = "com.whatever.RoundedBorder" color = "0xff0000">
notice that since components of this type are instantiated within the wicket XHTML namespace that there is no need to prefix the name with "wicket-". also, note that it is not necessary to use a <wicket:params> tag (and such a <wicket:params> tag is not allowed here... only after <tag id = "wicket-foo"> tags!) to pass arguments, as any attributes can be added to the tag and will set properties on the object.
finally, you can make abbreviations for any class through ApplicationSettings.addComponentClassAbbreviation() like this:
settings.addComponentClassAbbreviation("roundedBorder", com.whatever.RoundedBorder);
then you can say just:
<wicket:component class = "roundedBorder" color = "0xff0000">
last thing i can think of is that the RoundedBorder class might go into core if it is general enough and the BoxBorder class should be given a default abbreviation in ApplicationSettings of "boxBorder" so people can just say <wicket:component class = "boxBorder"> to get a box border.
i think that's it. any comments? clarifications needed?
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
