You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by kan <ka...@gmail.com> on 2009/02/16 17:22:39 UTC
.html-templates compiler
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: .html-templates compiler
Posted by Andreas Petersson <an...@petersson.at>.
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)
<p>Some dummy labelText</p>
or ...
@WicketRemove
<li>additional 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 +0000, kan <ka...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: .html-templates compiler
Posted by Timo Rantalaiho <Ti...@ri.fi>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: .html-templates compiler
Posted by kan <ka...@gmail.com>.
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 <ig...@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 <ka...@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 <ig...@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 <ka...@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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> WBR, kan.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
WBR, kan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: .html-templates compiler
Posted by Igor Vaynberg <ig...@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 <ka...@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 <ig...@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 <ka...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> WBR, kan.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: .html-templates compiler
Posted by kan <ka...@gmail.com>.
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 <ig...@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 <ka...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
WBR, kan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: .html-templates compiler
Posted by Igor Vaynberg <ig...@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 <ka...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org