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
