I don't get what you guys are talking about. Can you give some
simple sample code?Gili On Fri, 11 Feb 2005 07:59:05 -0800, Jonathan Locke wrote: > >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 > ------------------------------------------------------- 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
