users, please give us your opinion: what is your take on generics with Wicket

[igor.vaynberg]

yes. thats what i meant by wrapping. when/if we evaluate this we can
obviously put more thought into what it will effect and how to make it
all work. right now it was just a two minute idea i had, and it may
yet forever stay that way.

-igor

On Thu, Jun 5, 2008 at 10:16 AM, James Carman
<james@...> wrote:

> This might also screw up stuff like CompoundPropertyModel, no?  We
> discussed this a bit on ##wicket.
>
> On Thu, Jun 5, 2008 at 11:44 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> i didnt mean the memory slot, i ment the actual default model each
>> component can have. if i can write something like this:
>>
>> add(new webmarkupcontainer("foo") {
>>  private imodel<person> model;
>>  protected void isvisible() { return model.getobject()!=null; });
>>
>> then i am perfectly happy. notice how there is no explicit ondetach()
>> to detach the model. also notice how not having a default model slot
>> really removes the need for typing the component itself, i can
>> implement my own typed getmodel() easily. the only thing that breaks
>> here is wrapping since we no longer have a setmodel...something to
>> think about
>>
>> -igor
>>
>> On Thu, Jun 5, 2008 at 12:53 AM, Johan Compagner <jcompagner@...> wrote:
>>> like matej already told you
>>> There is no default "slot" or field..
>>> A component with no model doesnt have a a slot what so ever.
>>>
>>> johan
>>>
>>>
>>> On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg <igor.vaynberg@...>
>>> wrote:
>>>
>>>> like i said, i dont mind removing the default slot if we add nice
>>>> automatic detachment for fields.
>>>>
>>>> -igor
>>>>
>>>>
>>>> On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
>>>> <eelco.hillenius@...> wrote:
>>>> > On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg <igor.vaynberg@...>
>>>> wrote:
>>>> >> i dont think it exposes anything, or that anything is flawed. the
>>>> >> component provides a slot for a default model - it is there totally
>>>> >> out of convinience. i think what is flawed here is that we tied the
>>>> >> two types via generics.
>>>> >
>>>> > It depends on how you phrase things. It is a fact that currently
>>>> > models and components are tightly bound because of 'getModelObject'.
>>>> >
>>>> > The main issue is that with 1.3 you can simply omit the model, whereas
>>>> > with generified components the choice to not use a model is explicit
>>>> > (whether you use void, or an annotation to ignore warnings). Very
>>>> > annoying if you ask me, and it triggered me to think that this is
>>>> > another hint that the one-one relationship between components and
>>>> > models like we have now is somewhat flawed. I'm not saying it totally
>>>> > stinks and that we should get rid of it tomorrow, just that it is
>>>> > something we might rethink. You know I'm a fan of rethinking stuff ;-)
>>>> >
>>>> > Eelco
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: users-unsubscribe@...
>>>> > For additional commands, e-mail: users-help@...
>>>> >
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jwcarman]

Personally, I find CompoundPropertyModel too "magicy" for my tastes
anyway.  Yes, it's very convenient to just use property names for
component ids and it all just works out fine, but that can sometimes
be difficult to understand from a new person's perspective.  When
learning a technology, I don't really like it when folk say "just do
it this way; it works; trust me."  When I first started using
CompoundPropertyModel, I had these questions (and I'm sure others, but
this is all I can think of right now)?

1.  How far up the chain does a Component go looking for something to
base its property expression on?
2.  If I have a model on a Component in between my Component and the
Component containing the CPM, will it be smart enough to "skip over"
the intermediate model and travel up to the real one I want?
3.  What happens if I change property names!?

Maybe it's just me and I like to know how things work! :)  I used to
take apart my toys as a kid and I could never quite get them back
together the way they came.

James

On Thu, Jun 5, 2008 at 1:20 PM, Igor Vaynberg <igor.vaynberg@...> wrote:

> yes. thats what i meant by wrapping. when/if we evaluate this we can
> obviously put more thought into what it will effect and how to make it
> all work. right now it was just a two minute idea i had, and it may
> yet forever stay that way.
>
> -igor
>
> On Thu, Jun 5, 2008 at 10:16 AM, James Carman
> <james@...> wrote:
>> This might also screw up stuff like CompoundPropertyModel, no?  We
>> discussed this a bit on ##wicket.
>>
>> On Thu, Jun 5, 2008 at 11:44 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
>>> i didnt mean the memory slot, i ment the actual default model each
>>> component can have. if i can write something like this:
>>>
>>> add(new webmarkupcontainer("foo") {
>>>  private imodel<person> model;
>>>  protected void isvisible() { return model.getobject()!=null; });
>>>
>>> then i am perfectly happy. notice how there is no explicit ondetach()
>>> to detach the model. also notice how not having a default model slot
>>> really removes the need for typing the component itself, i can
>>> implement my own typed getmodel() easily. the only thing that breaks
>>> here is wrapping since we no longer have a setmodel...something to
>>> think about
>>>
>>> -igor
>>>
>>> On Thu, Jun 5, 2008 at 12:53 AM, Johan Compagner <jcompagner@...> wrote:
>>>> like matej already told you
>>>> There is no default "slot" or field..
>>>> A component with no model doesnt have a a slot what so ever.
>>>>
>>>> johan
>>>>
>>>>
>>>> On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg <igor.vaynberg@...>
>>>> wrote:
>>>>
>>>>> like i said, i dont mind removing the default slot if we add nice
>>>>> automatic detachment for fields.
>>>>>
>>>>> -igor
>>>>>
>>>>>
>>>>> On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
>>>>> <eelco.hillenius@...> wrote:
>>>>> > On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg <igor.vaynberg@...>
>>>>> wrote:
>>>>> >> i dont think it exposes anything, or that anything is flawed. the
>>>>> >> component provides a slot for a default model - it is there totally
>>>>> >> out of convinience. i think what is flawed here is that we tied the
>>>>> >> two types via generics.
>>>>> >
>>>>> > It depends on how you phrase things. It is a fact that currently
>>>>> > models and components are tightly bound because of 'getModelObject'.
>>>>> >
>>>>> > The main issue is that with 1.3 you can simply omit the model, whereas
>>>>> > with generified components the choice to not use a model is explicit
>>>>> > (whether you use void, or an annotation to ignore warnings). Very
>>>>> > annoying if you ask me, and it triggered me to think that this is
>>>>> > another hint that the one-one relationship between components and
>>>>> > models like we have now is somewhat flawed. I'm not saying it totally
>>>>> > stinks and that we should get rid of it tomorrow, just that it is
>>>>> > something we might rethink. You know I'm a fan of rethinking stuff ;-)
>>>>> >
>>>>> > Eelco
>>>>> >
>>>>> > ---------------------------------------------------------------------
>>>>> > To unsubscribe, e-mail: users-unsubscribe@...
>>>>> > For additional commands, e-mail: users-help@...
>>>>> >
>>>>> >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

There are plenty of cases where there isn't much risk and where using
CompoundPropertyModels is just convenient and leads to nicer readable
(imho) code. I use those models quite a bit, and I like them. I use
plenty of other (custom LDMs mainly) as well though.

Eelco

On Thu, Jun 5, 2008 at 10:29 AM, James Carman
<james@...> wrote:

> Personally, I find CompoundPropertyModel too "magicy" for my tastes
> anyway.  Yes, it's very convenient to just use property names for
> component ids and it all just works out fine, but that can sometimes
> be difficult to understand from a new person's perspective.  When
> learning a technology, I don't really like it when folk say "just do
> it this way; it works; trust me."  When I first started using
> CompoundPropertyModel, I had these questions (and I'm sure others, but
> this is all I can think of right now)?
>
> 1.  How far up the chain does a Component go looking for something to
> base its property expression on?
> 2.  If I have a model on a Component in between my Component and the
> Component containing the CPM, will it be smart enough to "skip over"
> the intermediate model and travel up to the real one I want?
> 3.  What happens if I change property names!?
>
> Maybe it's just me and I like to know how things work! :)  I used to
> take apart my toys as a kid and I could never quite get them back
> together the way they came.
>
> James
>
> On Thu, Jun 5, 2008 at 1:20 PM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> yes. thats what i meant by wrapping. when/if we evaluate this we can
>> obviously put more thought into what it will effect and how to make it
>> all work. right now it was just a two minute idea i had, and it may
>> yet forever stay that way.
>>
>> -igor
>>
>> On Thu, Jun 5, 2008 at 10:16 AM, James Carman
>> <james@...> wrote:
>>> This might also screw up stuff like CompoundPropertyModel, no?  We
>>> discussed this a bit on ##wicket.
>>>
>>> On Thu, Jun 5, 2008 at 11:44 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
>>>> i didnt mean the memory slot, i ment the actual default model each
>>>> component can have. if i can write something like this:
>>>>
>>>> add(new webmarkupcontainer("foo") {
>>>>  private imodel<person> model;
>>>>  protected void isvisible() { return model.getobject()!=null; });
>>>>
>>>> then i am perfectly happy. notice how there is no explicit ondetach()
>>>> to detach the model. also notice how not having a default model slot
>>>> really removes the need for typing the component itself, i can
>>>> implement my own typed getmodel() easily. the only thing that breaks
>>>> here is wrapping since we no longer have a setmodel...something to
>>>> think about
>>>>
>>>> -igor
>>>>
>>>> On Thu, Jun 5, 2008 at 12:53 AM, Johan Compagner <jcompagner@...> wrote:
>>>>> like matej already told you
>>>>> There is no default "slot" or field..
>>>>> A component with no model doesnt have a a slot what so ever.
>>>>>
>>>>> johan
>>>>>
>>>>>
>>>>> On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg <igor.vaynberg@...>
>>>>> wrote:
>>>>>
>>>>>> like i said, i dont mind removing the default slot if we add nice
>>>>>> automatic detachment for fields.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
>>>>>> <eelco.hillenius@...> wrote:
>>>>>> > On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg <igor.vaynberg@...>
>>>>>> wrote:
>>>>>> >> i dont think it exposes anything, or that anything is flawed. the
>>>>>> >> component provides a slot for a default model - it is there totally
>>>>>> >> out of convinience. i think what is flawed here is that we tied the
>>>>>> >> two types via generics.
>>>>>> >
>>>>>> > It depends on how you phrase things. It is a fact that currently
>>>>>> > models and components are tightly bound because of 'getModelObject'.
>>>>>> >
>>>>>> > The main issue is that with 1.3 you can simply omit the model, whereas
>>>>>> > with generified components the choice to not use a model is explicit
>>>>>> > (whether you use void, or an annotation to ignore warnings). Very
>>>>>> > annoying if you ask me, and it triggered me to think that this is
>>>>>> > another hint that the one-one relationship between components and
>>>>>> > models like we have now is somewhat flawed. I'm not saying it totally
>>>>>> > stinks and that we should get rid of it tomorrow, just that it is
>>>>>> > something we might rethink. You know I'm a fan of rethinking stuff ;-)
>>>>>> >
>>>>>> > Eelco
>>>>>> >
>>>>>> > ---------------------------------------------------------------------
>>>>>> > To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> > For additional commands, e-mail: users-help@...
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>>> For additional commands, e-mail: users-help@...
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

On Thu, Jun 5, 2008 at 10:20 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
> yes. thats what i meant by wrapping. when/if we evaluate this we can
> obviously put more thought into what it will effect and how to make it
> all work. right now it was just a two minute idea i had, and it may
> yet forever stay that way.

I think it would be good to discuss this when everyone is read for it.
I for one would like to explore alternatives to what we currently
have. But to have that discussion now would be a waste of our time.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jwcarman]

On Thu, Jun 5, 2008 at 1:45 PM, Eelco Hillenius
<eelco.hillenius@...> wrote:
> On Thu, Jun 5, 2008 at 10:20 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> yes. thats what i meant by wrapping. when/if we evaluate this we can
>> obviously put more thought into what it will effect and how to make it
>> all work. right now it was just a two minute idea i had, and it may
>> yet forever stay that way.
>
> I think it would be good to discuss this when everyone is read for it.
> I for one would like to explore alternatives to what we currently
> have. But to have that discussion now would be a waste of our time.

Right, we need to figure out what we're going to do for 1.4.  Have we
decided on that?  It seems like a lot of folks like the idea of making
the model methods non-final on Component, thereby allowing components
to "type themselves" by overriding them (using JDK5 covariant return
types) when it makes sense (ListView, Item, etc.).  This hybrid
approach seems like it would be a good compromise.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

> Right, we need to figure out what we're going to do for 1.4.  Have we
> decided on that?  It seems like a lot of folks like the idea of making
> the model methods non-final on Component, thereby allowing components
> to "type themselves" by overriding them (using JDK5 covariant return
> types) when it makes sense (ListView, Item, etc.).  This hybrid
> approach seems like it would be a good compromise.

I'm still on the fence. I was thinking that it might make a good topic
to talk about - and decide upon - next week, when everyone has had a
good rest and the dust has settled down etc. :-)

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Johan Compagner]

next week a good rest?
next week i dont have much rest.. I am on vacation!
Bern, Switzerland!

johan


On Thu, Jun 5, 2008 at 8:05 PM, Eelco Hillenius <eelco.hillenius@...>
wrote:

> > Right, we need to figure out what we're going to do for 1.4.  Have we
> > decided on that?  It seems like a lot of folks like the idea of making
> > the model methods non-final on Component, thereby allowing components
> > to "type themselves" by overriding them (using JDK5 covariant return
> > types) when it makes sense (ListView, Item, etc.).  This hybrid
> > approach seems like it would be a good compromise.
>
> I'm still on the fence. I was thinking that it might make a good topic
> to talk about - and decide upon - next week, when everyone has had a
> good rest and the dust has settled down etc. :-)
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Stefan Lindner]

Johan Compagner wrote
>next week i dont have much rest.. I am on vacation!
>Bern, Switzerland!

You are visiting an EM match? That's not a rest? :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Tsutomu Yano]

On 2008/06/02, at 5:44, Eelco Hillenius wrote:

> 1) Generifying* Wicket

  [X] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.

  For me, the most important thing is that component's getModelObject() method
returns a object with correct type, which the IModel have, without casting.
If it will be not realized, generifying Wicket have no mean.

  it is needed generifying both of components and models to realize that.
If components will be not generified, getModelObject() method will return Object type always,
then I need casting it.
  I often usegetModelObject() method.


>  2) How strongly do you feel about your choice above?


  [X] I might rethink upgrading if my choice doesn't win.


  However, I can understand that the way like Page<Void>, Link<Void> is
verbose. So we can avoid the verbosity creating some generic classes for components.
Like:

  - Page<T>
  - GenericPage extends BasePage<Void>

  If I want not write Page<Void>, you can simply use GenericPage class instead.

----------------------
Tsutomu YANO
benbrand at mac.com
Tokyo, Japan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ivo van Dongen-2]

>
> 1) Generifying* Wicket
>    [ X ] Can best be done in a limited fashion, where we only generify
> IModel but not components. I care more about what generifying can do
> for API clarity (declaring a component to only accept certain models
> for instance) than static type checking.
>
> 2) How strongly do you feel about your choice above?
>    [ X ] I might rethink upgrading if my choice doesn't win.
>
>  

Regards,
Ivo


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[xiefei-2]

 [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket.
 I am just a little annoyed when a component not having a model causes generics warning.
 
 [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up.
_________________________________________________________________
MSN 中文网，最新时尚生活资讯，白领聚集门户。
http://cn.msn.com

[Daniel Walmsley]

> 1) Generifying* Wicket
>   [X] Can best be done like currently in the 1.4 branch, where models
> and components are both generified. I care most about the improved
> static type checking generified models and components give Wicket.

> 2) How strongly do you feel about your choice above?
>   [X] Whatever choice ultimately made, I'll happily convert/ start
> using 1.4 and up.

**reason**

Strong typing is my friend. Refactoring is my friend. The stronger and  
clearer we make typing throughout Wicket the happier I'll be.

Code is written once and maintained a hundred thousand times. I'd  
always trade verbosity for maintainability.

D


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Peter Ertl]

>
> Strong typing is my friend. Refactoring is my friend. The stronger  
> and clearer we make typing throughout Wicket the happier I'll be.
>
> Code is written once and maintained a hundred thousand times. I'd  
> always trade verbosity for maintainability.

+1 for that --- very nice said! I totally agree :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Stefan Lindner]

> Strong typing is my friend. Refactoring is my friend. The stronger and

> clearer we make typing throughout Wicket the happier I'll be.
>
> Code is written once and maintained a hundred thousand times. I'd
> always trade verbosity for maintainability.

Yes! Good summary!

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Stefan Lindner]

I want to use a JavaScript library that requires the body to be loaded.
This can normally be done by writing

        <body>
                <script>......</script>
        </body>

What is the correct way to do this in wicket 1.4?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[igor.vaynberg]

build the <script> as a label and add it to the page. set
escapemodelstrings(false) on it and wicket wont escape any makrup.

-igor

On Mon, Jun 9, 2008 at 4:39 AM, Stefan Lindner <lindner@...> wrote:

> I want to use a JavaScript library that requires the body to be loaded.
> This can normally be done by writing
>
>        <body>
>                <script>......</script>
>        </body>
>
> What is the correct way to do this in wicket 1.4?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jwcarman]

This is a common enough scenario that perhaps there should be a
built-in facility for it?  I was wondering how to insert the Google
Analytics javascript code right before my </body> tag too.

On Mon, Jun 9, 2008 at 10:42 AM, Igor Vaynberg <igor.vaynberg@...> wrote:

> build the <script> as a label and add it to the page. set
> escapemodelstrings(false) on it and wicket wont escape any makrup.
>
> -igor
>
> On Mon, Jun 9, 2008 at 4:39 AM, Stefan Lindner <lindner@...> wrote:
>> I want to use a JavaScript library that requires the body to be loaded.
>> This can normally be done by writing
>>
>>        <body>
>>                <script>......</script>
>>        </body>
>>
>> What is the correct way to do this in wicket 1.4?
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[igor.vaynberg]

add a label in your basepage right before the </body> tag? you do own
the markup do you not?

-igor

On Mon, Jun 9, 2008 at 7:45 AM, James Carman <james@...> wrote:

> This is a common enough scenario that perhaps there should be a
> built-in facility for it?  I was wondering how to insert the Google
> Analytics javascript code right before my </body> tag too.
>
> On Mon, Jun 9, 2008 at 10:42 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> build the <script> as a label and add it to the page. set
>> escapemodelstrings(false) on it and wicket wont escape any makrup.
>>
>> -igor
>>
>> On Mon, Jun 9, 2008 at 4:39 AM, Stefan Lindner <lindner@...> wrote:
>>> I want to use a JavaScript library that requires the body to be loaded.
>>> This can normally be done by writing
>>>
>>>        <body>
>>>                <script>......</script>
>>>        </body>
>>>
>>> What is the correct way to do this in wicket 1.4?
>>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jwcarman]

I haven't actually implemented my Google Analytics stuff yet.  It has
thus far been merely a thought experiment.

On Mon, Jun 9, 2008 at 10:46 AM, Igor Vaynberg <igor.vaynberg@...> wrote:

> add a label in your basepage right before the </body> tag? you do own
> the markup do you not?
>
> -igor
>
> On Mon, Jun 9, 2008 at 7:45 AM, James Carman <james@...> wrote:
>> This is a common enough scenario that perhaps there should be a
>> built-in facility for it?  I was wondering how to insert the Google
>> Analytics javascript code right before my </body> tag too.
>>
>> On Mon, Jun 9, 2008 at 10:42 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
>>> build the <script> as a label and add it to the page. set
>>> escapemodelstrings(false) on it and wicket wont escape any makrup.
>>>
>>> -igor
>>>
>>> On Mon, Jun 9, 2008 at 4:39 AM, Stefan Lindner <lindner@...> wrote:
>>>> I want to use a JavaScript library that requires the body to be loaded.
>>>> This can normally be done by writing
>>>>
>>>>        <body>
>>>>                <script>......</script>
>>>>        </body>
>>>>
>>>> What is the correct way to do this in wicket 1.4?
>>>>
>>>> Stefan
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Philip A. Chapman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I vote the same way. with almost the exact same sentiments.

Wouter de Vaal wrote:

>> 1) Generifying* Wicket
>>   [x] Can best be done like currently in the 1.4 branch, where models
>> and components are both generified. I care most about the improved
>> static type checking generified models and components give Wicket.
>
> I had a production quality project with the old 2.0 branch (downgraded it) and
> that worked just fine and very intuitive, I was very bummed at the time
> I had to add all these hideous type casts. I do not understand the fuss about
> generifying everything, I did not have ANY problems using the generics in
> my production project (which consists of about 30 wicket classes) and it
> was not a simple crud app, I did some funky wicket stuff with this
> project (loads
> of panels, fragment, own custom component, ajax) and it all just worked.
>> 2) How strongly do you feel about your choice above?
>>   [X] Whatever choice ultimately made, I'll happily convert/ start
>> using 1.4 and up.
>
>
> Wouter de Vaal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

- --
Philip A. Chapman

Desktop and Web Application Development:
Java, .NET, PostgreSQL, MySQL, MSSQL
Linux, Windows 2000, Windows XP

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIUHzDAdpynRSGw3URAkdFAJsFWUKlbu27zE2LidYx3HdJUZt4cQCcDBX/
Ner0sbazi8jh/EllYZVgW1s=
=WPF9
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...