yeah, i wonder if we don't need two components for most javascript... the component down
in the tree that is contributing javascript and the component up the tree that is receiving it.
to tie the two together, maybe some naming convention or attribute?
Kamil Rembalski wrote:
Still, there I have one more problem: some DHTML/JS scripts may require a <div> where JS output can be written. This is the case with my calendar. The point is that:
- it should be declared right after the <body> tag - in the js file, I must know its exact name - if I'll put it inside the form tags, it will be "form.something". Of course, when I'm writing the component, I do not know where the user will put it. - it should be displayed once for all calendar components - there is no need to display it a few times.
I do not know what to do with it - I was thinking if this case show the need for another "insertion point", and if it does - how many of other places like this can be identified in an html document...
I got seriously confused with this.
Regards, Kamil
On Fri, 11 Feb 2005 11:51:42 +0100, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
Excellent point!
Eelco
Kamil Rembalski wrote:
Hi guys,
Instead of checking if a method/variable already exeists, I was thinking about something else: There should be a way to contribute javascript code in two ways : "component global", for supplying the js code that should be rendered once per component TYPE and "component local".
For example, in the calendar component, there is no need to double all the functions. So, the page/whatever else should remember that one component of type calendar was already added and that there is no need to supply global JS code. On the other hand, each calendar may need its own JS variables. These should be rendered and renamed for each calendar. Taking care of renaming the variables should be component's author job.
"component global" JS could be supplied via JS files, and local - via JS code embedded in <scripts> tag.
This would be easier to do then parsing the JS files. In order to prevent component developers from creating functions with the same names (in different components), there should be a guideline to add the component name as a prefix to all variables.
Regards, Kamil
On Fri, 11 Feb 2005 09:50:24 +0100, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I agree. In real life usecases, you'll usually want to focus on including JS etc as a file instead of inlining, as these file can be cached. Now, if we could include those resources as packaged resources, a major problem would allready have been tackled.
I don't know about checking whether Javascript methods allready exist etc. The whole parsing process will get a lot heavier from it, and I think that it is the responsibility of the developpers as well? Btw, having layered CSS (same class, selectors, etc) is not illegal.
Eelco
Jonathan Locke wrote:
Gili wrote:
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.
this makes good sense. starting simple is how wicket itself evolved. the trick will be to have some idea how the simple case might evolve, even if that isn't implemented in 1.0.
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.
this sounds like a good start and that seems like the right way to add links, but i want to avoid any kind of file generation. better to add the code inline, even if the problem is a little harder.
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?
yup.
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
------------------------------------------------------- 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
------------------------------------------------------- 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
------------------------------------------------------- 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
