With a more practical use-case it is hard for me to comment,
but this whole talk of "global" versus "local" sounds a lot to me like
static versus non-static peer variables associated with a Wicket
component.
Can someone provide a simple testcase?
Gili
On Fri, 11 Feb 2005 11:42:48 +0100, 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
