My 2 cents... The topic of CSS and JS are very deep and you
could spend months trying to come up with "the ultimate solution".
Instead, I suggest you come up with simple use-cases that depend on CSS
and JS, design Wicket for those cases and incrementally increase the
complexity of the use-case.
You don't necessary need to handle all use-cases anyway. Just
get a slick design going for the most common use-cases and grow from
there.
Personally, I think the best way to start is by forcing all CSS
and JS to be found on separate pages (that is, we don't support inline
CSS/JS at this time). If components associate a JS or CSS component
with themselves (using add() or some other mechanism) then at Page
rendering time, the Page walks through all subcomponents recursively,
picks up their JS/CSS dependencies and automatically outputs links to
those external CSS/JS pages at the top of the page. The JS/CSS files
are also dynamically generated.
That's probably far from being a perfect solution, but it's a
fairly clean beginning and we could work from there. The way I see it,
JS/CSS are "peers" of a Wicket component. In a sense, the markup (html)
of a Wicket component is somewhat of a peer itself. Does this make
sense?
Gili
On Thu, 10 Feb 2005 18:33:46 -0800, Jonathan Locke wrote:
>
>okay, why don't we start brainstorming our requirements for this?
>
>a few things that occur to me:
>
> - components ought to be able to contribute javascript methods to the
>header section
> - adding javascript needs to be smart in terms of merging things. if a
>javascript function already exists, it should be left alone
> - ordering of contributions is going to be important, particularly in css
> - could make javascript contributions modular via .js files included
>with the <script src="foo.js"/> syntax
> - javascript .js files could be loaded in the same way that markup
>files are loaded via resource locator code
> - need support for easily adding javascript invokations to various html
>attributes
> - client side validation should be added through the existing
>validation api, which should contribute javascript code to the header
>and the form button onclick handler
>
>i don't have deep javascript knowledge, so everyone's embellishments and
>thoughts are extra important.
>some examples of common javascript tasks as well as ideas about how
>things might best work would be helpful.
>
> jon
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Wicket-develop mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
