interface/visitor. i even gave the exact interface yesterday...
it's less efficient, but it's much more flexible. for components to register themselves, they'd have to know where to do that. better for the framework to come find them i think... a traversal of a page's components is probably like lightning for the most part. there aren't a huge number of components on your average page. but if there were, this interface approach would still be better and we could just change our approach to hooking them up by trying to collect the interface implementing components during calls to add() and/or replace() methods in some efficient way. i don't think that's worth it for now.
Eelco Hillenius wrote:
Are you thinking about letting such components register themselves somewhere, or should such components implement an interface and use a visitor to collect the contributions? I think I would prefer the latter, though that would also be less efficient.
Eelco
Jonathan Locke wrote:
btw, i wanted to point out that this component that gets inserted in the header can be installed in
a base page class for your application and you'll never have to think about it again...
Jonathan Locke wrote:
i'm not sure i like the idea of automatic header insertions. i think you should place a component
in the header or wherever where you want the stuff to go. this is more obvious and self-documenting
and takes care of problems where the insertion point might matter for one reason or another.
in the first case, why even have a syntax for insertGlobalCSS? this unnecessarily makes wysiwyg
impossible and adds a concept that isn't needed. why not just parse the links in the document?
same goes with javascript... basically, i think wicket could have the API i described yesterday
(roughly), but be smart enough to automatically pull javascript and css links out of a component...
that would be much more powerful and intuitive.
i also think in some future version, the javascript insertion code ought to do a javacc parse of the
javascript enough to determine what needs scoping. it should then namespace variables and functions.
this really doesn't need doing /right now/ though as long as component authors know that they ought
to namespace their own variables and functions if they want their component to be reusable.
Kamil Rembalski wrote:
OK.
Here is a simple example. This is how I would like my component's markup to look like: -------------------------------------- <wicket:insertGlobalCSS> styles.css </wicket:insertGlobalCSS>
<wicket:insertGlobalJS> function globalFution(){ //this function will be rendered only once per //component type }
var global variable; </wicket:insertGlobalJS>
<wicket:insertGlobalHTML>
<div id="myDiv">This text is rendered once per component type.</div>
</wicket:insertGlobalHTML>
<script> var localVar; function localFunction(){ //this function is rendered for every component. } </script> <p>My component</p> ------------------------------------------
I'll try to make this as short as possible. When the page is parsed, all "global" inserts should be found and stored. Text surrounded by those tag should be displayed in appropriate places only once per component type - this should be done automatically by the framework. I did not do anything to the component script - according to HTML spec script tag may appear many times in both head and body, so I think that component author can just leave it there. Of course, I should take care of renaming my component - maybe there should be some support for it.
This is a very simplistic solution. I do not think that there should be special components for this. It is enough to detect the right places in the markup and insert text there.
Problem: what if somebody's page does not have head section, to put the css in? - i think that it should be automatically created then...
Cheers, Kamil
On Sat, 12 Feb 2005 08:31:17 -0800, Jonathan Locke <[EMAIL PROTECTED]> wrote:
sorry, but i don't understand you.
specifically, how would you change my proposal?
Gili wrote:
On Fri, 11 Feb 2005 23:19:15 -0800, Jonathan Locke wrote:
unlike most wicket components, a CSS link component would generate HTML
rather than
modify it. so i think the wicket namespace syntax might be best.
something like:
I don't think the link should generate HTML. The link should
just connect you to a CSS peer object. I think the entity responsible
for triggering CSS rendering should be the Page if it's inline or the
component that links to it if it's external (the external file is only
rendered the first time, even if it's linked to by multiple
components).
Gili
Gili wrote:
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
-------------------------------------------------------
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
