Re: .html-templates compiler
On Tue, 17 Feb 2009, kan wrote: I mean if you have a wicket:id=abc, it will generate class with... emm... not sure, say method getAbc() which will return an object which represents an element, so it can be bound to a Component. So, in java-code you can use only elements which are actually exist in html-markup. We do automatic tests for our Wicket components with WicketTester, and they pretty much do this kind of checking. And have other benefits besides :) Best wishes, Timo - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: .html-templates compiler
I mean if you have a wicket:id=abc, it will generate class with... emm... not sure, say method getAbc() which will return an object which represents an element, so it can be bound to a Component. So, in java-code you can use only elements which are actually exist in html-markup. Maybe something similar then set of java classes are generated for wsdl or xsd. 2009/2/16 Igor Vaynberg igor.vaynb...@gmail.com: sorry, what are you trying to do with this? if we preparse the markup and break it up into tags at compile time we still have to store it somehow and load it at runtime. so that format would need to be more efficient at storing markup than xml already is, but the parser is a very tinny percentage of the request and it only happens on the first load of markup - we cache the parsed structure. so you would have a very small gain at the high price of introducing a compilation step into the build process... is it worth it? -igor On Mon, Feb 16, 2009 at 9:46 AM, kan kan@gmail.com wrote: But html-template just is a regular file, a class resource compiled in jar, you cannot change/generate it dynamically in run-time. Dynamic markup allows to build a component-tree in run-time, but doesn't allow to change html-template or assigned java-class itself. 2009/2/16 Igor Vaynberg igor.vaynb...@gmail.com: the point of all those wicket:ids is to generate dynamic markup. dynamic meaning runtime. -igor On Mon, Feb 16, 2009 at 8:22 AM, kan kan@gmail.com wrote: Just random thought... Has anybody thought to make wicket html-template compiler? I think it could be quite useful - it can check all wicket:id, all hrefs and so on checked at compile-time. And also it can gain some performance, because it will not require to parse html at run-time. -- WBR, kan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- WBR, kan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- WBR, kan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: .html-templates compiler
well, that is not really what wicket does right now. i think it would be interesting to tie the markup + code more tightly together, to have the compiler already check for correctness, instead of runtime. for example warp-widgets ( http://code.google.com/p/warp-core/ ) does this in an elegant way at compile-time, using MVEL ( http://mvel.codehaus.org/ ) *i have not thought it through*, but it may be possible to annotate the html like warp-widgets does, to tie the wicket ids to constants/enums and keep everything else(pages/panels) in java code the same. this could be a typesave alternative to wicket:id, so you will not be able to compile if you didn't supply the enum. @Wicket(id=MyWebPage.BLA) pSome dummy labelText/p or ... @WicketRemove liadditional BulletPoint/li i should do a proof-of-concept when my project is finished :) best regards andreas On Tue, 17 Feb 2009 08:52:01 +, kan kan@gmail.com wrote: I mean if you have a wicket:id=abc, it will generate class with... emm... not sure, say method getAbc() which will return an object which represents an element, so it can be bound to a Component. So, in java-code you can use only elements which are actually exist in html-markup. Maybe something similar then set of java classes are generated for wsdl or xsd. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: .html-templates compiler
the point of all those wicket:ids is to generate dynamic markup. dynamic meaning runtime. -igor On Mon, Feb 16, 2009 at 8:22 AM, kan kan@gmail.com wrote: Just random thought... Has anybody thought to make wicket html-template compiler? I think it could be quite useful - it can check all wicket:id, all hrefs and so on checked at compile-time. And also it can gain some performance, because it will not require to parse html at run-time. -- WBR, kan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: .html-templates compiler
But html-template just is a regular file, a class resource compiled in jar, you cannot change/generate it dynamically in run-time. Dynamic markup allows to build a component-tree in run-time, but doesn't allow to change html-template or assigned java-class itself. 2009/2/16 Igor Vaynberg igor.vaynb...@gmail.com: the point of all those wicket:ids is to generate dynamic markup. dynamic meaning runtime. -igor On Mon, Feb 16, 2009 at 8:22 AM, kan kan@gmail.com wrote: Just random thought... Has anybody thought to make wicket html-template compiler? I think it could be quite useful - it can check all wicket:id, all hrefs and so on checked at compile-time. And also it can gain some performance, because it will not require to parse html at run-time. -- WBR, kan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- WBR, kan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: .html-templates compiler
sorry, what are you trying to do with this? if we preparse the markup and break it up into tags at compile time we still have to store it somehow and load it at runtime. so that format would need to be more efficient at storing markup than xml already is, but the parser is a very tinny percentage of the request and it only happens on the first load of markup - we cache the parsed structure. so you would have a very small gain at the high price of introducing a compilation step into the build process... is it worth it? -igor On Mon, Feb 16, 2009 at 9:46 AM, kan kan@gmail.com wrote: But html-template just is a regular file, a class resource compiled in jar, you cannot change/generate it dynamically in run-time. Dynamic markup allows to build a component-tree in run-time, but doesn't allow to change html-template or assigned java-class itself. 2009/2/16 Igor Vaynberg igor.vaynb...@gmail.com: the point of all those wicket:ids is to generate dynamic markup. dynamic meaning runtime. -igor On Mon, Feb 16, 2009 at 8:22 AM, kan kan@gmail.com wrote: Just random thought... Has anybody thought to make wicket html-template compiler? I think it could be quite useful - it can check all wicket:id, all hrefs and so on checked at compile-time. And also it can gain some performance, because it will not require to parse html at run-time. -- WBR, kan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- WBR, kan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
