you know, i think we really need to say no to this feature in 1.0
we've got a huge amount of work to do to finish just the features we've got.
we want to ship a really compelling and polished product. opening the
focus up again is not going to help us do that. the risk here is that wicket
never really ships and never gets the attention it deserves. let's try to do
what we've already been trying to do well and save more features for later.
Gili wrote:
The one problem I see with CSS which has not been cleanly handled by any other framework is the fact that CSS is detached from the code it marks up. This usually leads to developers creating two components: one for building the CSS and another for building the component it marks up (i.e. RoundBorderBorder is such a case).
Ideally, we should be able to unify these two so one can create a single component that has an associated CSS and HTML code and they can be built in one place in order to reduce mismatches and errors. Users can still develop CSS and HTML separately -- but at least they'll have the option.
Please note I am refering to CSS that is not a "general markup" of "general HTML". I am discussing CSS that marks up *specific* sections of HTML -- like "mark up my round border border here in this manner ... this doesn't apply to anything else in the page".
Gili
On Tue, 18 Jan 2005 17:40:23 +0100, Juergen Donnerstag wrote:
Without havng thought about how to implement it, what are the requirements for the javascript / css support.
a) each html component should support it b) Javascript / css should be part of the components markup and enclosed by some tags (e.g. <wicket:javascript>) which identifies the region c) Such region should be rendered only once per page, no matter how many components of the same type are on the same page. d) we need to support for the page html to determine where to insert the javascript region. We must support multiple markers (add to <head> or <body> e.g.) what else?
problems I see without having deeply thought about. We are currently scanning the markup and if required we read a sub-component markup and include it. This approach might not work out for javascript / css regions due to the requirements mentioned above.
Juergen
------------------------------------------------------- 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
