Re: Wicket feedback

[Igor Vaynberg]

so do it with wicket. nothing is stopping you. i know of a few
projects that have a working gwt integration, but they are not open
source. so its possible, and quiet easily.

-igor


On Tue, Dec 22, 2009 at 10:32 PM, Sudhir N  wrote:
> One more thing I am still looking for is, integrating GWT. I did that before 
> with other framework.
>
>
>
>
>
> Sudhir NimavatSenior software engineer.
> Quick start global PVT LTD.
> Baroda - 390007
> Gujarat, India
>
> Personally I'm always ready to learn, although I do not always like being 
> taught
>
>
>
>
>
> 
> From: "sudhir543-...@yahoo.com" 
> To: users@wicket.apache.org
> Sent: Wed, 23 December, 2009 11:57:34 AM
> Subject: Re: Wicket feedback
>
>
>> so how does webwork know which properties of your actions should be injected 
>> from spring and which from the request or session objects?
>
> - Actions can be configured as spring beans... webwork knows how to get it 
> from there, developer decides what dependencies should be managed by spring.
> - Action is available in valuestack, for example, when form is submitted, 
> webwork can set properties directly on your action or on your model if it is a
>  modal driven action. Interceptors does this.
>
>>it all depends on how your domain model works
> Sorry, but I don't get how LDM depends on domain model.. I belive by domain 
> model you mean, the core 'domain model design' of application. Entities and 
> relationships ?
>
>> when you need to put your entity into session because you want to access it 
>> across requests, or when you put things into conversation scope. this problem
> has nothing to do with wicket. LDM is simply one concrete solution for 
> dealing with these kinds of issues.
>
> During most of my past project, I was rarely if ever required to put entities 
> into session, most of the time alternatives worked.
> Wicket requires me to put entities into session and so provides LDM. So its 
> like a solution to its own need.
>
> I can understand that being a component oriented framework, wicket has lil 
> different needs, and thts fine most of time.
> My point was 'there's some overhead involved when working on integration of 
> other frameworks'.
>
> Thanks
> SN
>
>
>
>
> Sudhir NimavatSenior software engineer.
> Quick start global PVT LTD.
> Baroda - 390007
> Gujarat, India
>
> Personally I'm always ready to learn, although I do not always like being 
> taught
>
>
>
>
>
> 
> From: Igor Vaynberg 
> To: users@wicket.apache.org
> Sent: Wed, 23 December, 2009 2:13:37 AM
> Subject: Re: Wicket feedback
>
> On Tue, Dec 22, 2009 at 11:13 AM,   wrote:
>> Thanks for clarifying the things,
>>
>>> show me a framework that makes this easier...
>> I think that when I when I was working with Webwork (Struts2 now) I dint 
>> need to do any thing else other than specifying spring factory in one of 
>> config file. Neither I was forced to use annotations.
>
> so how does webwork know which properties of your actions should be
> injected from spring and which from the request or session objects?
>
>> LDMA might have nothing to do with Integration, but from my lil experience, 
>> I think that When I want to pass my entity as a model to some components 
>> (which might be serialized as in most cases) It wouldnt work with normal 
>> models, I will have to manage a separate LDM class for each of that if I 
>> don't want lazyloading exceptions.
>
> huh? it all depends on how your domain model works. every application
> is different. same applies to other frameworks - eg when you need to
> put your entity into session because you want to access it across
> requests, or when you put things into conversation scope. this problem
> has nothing to do with wicket. LDM is simply one concrete solution for
> dealing with these kinds of issues.
>
> -igor
>
>>
>>
>>
>>
>>
>> Sudhir NimavatSenior software engineer.
>> Quick start global PVT LTD.
>> Baroda - 390007
>> Gujarat, India
>>
>> Personally I'm always ready to learn, although I do not always like being 
>> taught
>>
>>
>>
>>
>>
>> 
>> From: Igor Vaynberg 
>> To: users@wicket.apache.org
>> Sent: Wed, 23 December, 2009 12:03:05 AM
>> Subject: Re: Wicket feedback
>>
>> On Tue, Dec 22, 2009 at 10:20 AM,   wrote:
>>> Yes, from my little experience, I just started learning it [Because I feel 
>>> it has some thing different to offer]
>>>
orly? so what about integrations with hibernate, jdo, jpa, spring,
>>> guice, cdi, etc? i guess all those things are a figment of my
>>> imagination.
>>>
>>> As I said it takes comparatively(to some others) more efforts.
>>> If I talk about spring, using spring with wicket needs special care, one 
>>> will have to take care that he > does not serialize entire containers.
>>
>> that is taken care for you by the framework. all you have to do is
>> install the component injector (1 line of code) and use @SpringBean
>> annotations in your pages to inject your d

Re: Wicket feedback

[Igor Vaynberg]

On Tue, Dec 22, 2009 at 10:27 PM,   wrote:
>> so how does webwork know which properties of your actions should be injected 
>> from spring and which from the request or session objects?
>
> - Actions can be configured as spring beans... webwork knows how to get it 
> from there, developer decides what dependencies should be managed by spring.
> - Action is available in valuestack, for example, when form is submitted, 
> webwork can set properties directly on your action or on your model if it is a
>  modal driven action. Interceptors does this.


well, so much for your "single line of code is all it takes", since
you also have to declare each action in spring's xml. or if you use
their new approach you get to put..wait for it..annotations into your
actions such as @Component and @Autowired. wicket's @SpringBean is
analogous to @Autowired.

>>it all depends on how your domain model works
> Sorry, but I don't get how LDM depends on domain model.. I belive by domain 
> model you mean, the core 'domain model design' of application. Entities and 
> relationships ?

some domain models are designed with serialization in mind. they make
it easy to take any domain object and safely serialize it, then at a
later time merge the changes using eg entitymanager.merge(entity).

others are not. their objects do not support serialization. these
models depend on some kind of dtos to allow mutation.

>> when you need to put your entity into session because you want to access it 
>> acrossrequests, or when you put things into conversation scope. this problem
> has nothing to do with wicket. LDM is simply one concrete solution for 
> dealing with these kinds of issues.
>
> During most of my past project, I was rarely if ever required to put entities 
> into session, most of the time alternatives worked.
> Wicket requires me to put entities into session and so provides LDM. So its 
> like a solution to its own need.

no, you are welcome to use alternatives, such as dtos.

> I can understand that being a component oriented framework, wicket has lil 
> different needs, and thts fine most of time.
> My point was 'there's some overhead involved when working on integration of 
> other frameworks'.

yeah, i still dont see any of this overhead. LDM has nothing to do
with integration of other frameworks anyways.

-igor

>
> Thanks
> SN
>
>
>
>
> Sudhir NimavatSenior software engineer.
> Quick start global PVT LTD.
> Baroda - 390007
> Gujarat, India
>
> Personally I'm always ready to learn, although I do not always like being 
> taught
>
>
>
>
>
> 
> From: Igor Vaynberg 
> To: users@wicket.apache.org
> Sent: Wed, 23 December, 2009 2:13:37 AM
> Subject: Re: Wicket feedback
>
> On Tue, Dec 22, 2009 at 11:13 AM,   wrote:
>> Thanks for clarifying the things,
>>
>>> show me a framework that makes this easier...
>> I think that when I when I was working with Webwork (Struts2 now) I dint 
>> need to do any thing else other than specifying spring factory in one of 
>> config file. Neither I was forced to use annotations.
>
> so how does webwork know which properties of your actions should be
> injected from spring and which from the request or session objects?
>
>> LDMA might have nothing to do with Integration, but from my lil experience, 
>> I think that When I want to pass my entity as a model to some components 
>> (which might be serialized as in most cases) It wouldnt work with normal 
>> models, I will have to manage a separate LDM class for each of that if I 
>> don't want lazyloading exceptions.
>
> huh? it all depends on how your domain model works. every application
> is different. same applies to other frameworks - eg when you need to
> put your entity into session because you want to access it across
> requests, or when you put things into conversation scope. this problem
> has nothing to do with wicket. LDM is simply one concrete solution for
> dealing with these kinds of issues.
>
> -igor
>
>>
>>
>>
>>
>>
>> Sudhir NimavatSenior software engineer.
>> Quick start global PVT LTD.
>> Baroda - 390007
>> Gujarat, India
>>
>> Personally I'm always ready to learn, although I do not always like being 
>> taught
>>
>>
>>
>>
>>
>> 
>> From: Igor Vaynberg 
>> To: users@wicket.apache.org
>> Sent: Wed, 23 December, 2009 12:03:05 AM
>> Subject: Re: Wicket feedback
>>
>> On Tue, Dec 22, 2009 at 10:20 AM,   wrote:
>>> Yes, from my little experience, I just started learning it [Because I feel 
>>> it has some thing different to offer]
>>>
orly? so what about integrations with hibernate, jdo, jpa, spring,
>>> guice, cdi, etc? i guess all those things are a figment of my
>>> imagination.
>>>
>>> As I said it takes comparatively(to some others) more efforts.
>>> If I talk about spring, using spring with wicket needs special care, one 
>>> will have to take care that he > does not serialize entire containers.
>>
>> that is taken care for you by the framework. all you have to do is
>>

Re: Wicket feedback

[Sudhir N]

One more thing I am still looking for is, integrating GWT. I did that before 
with other framework. 


 
  

Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: "sudhir543-...@yahoo.com" 
To: users@wicket.apache.org
Sent: Wed, 23 December, 2009 11:57:34 AM
Subject: Re: Wicket feedback


> so how does webwork know which properties of your actions should be injected 
> from spring and which from the request or session objects?

- Actions can be configured as spring beans... webwork knows how to get it from 
there, developer decides what dependencies should be managed by spring.
- Action is available in valuestack, for example, when form is submitted, 
webwork can set properties directly on your action or on your model if it is a 
  modal driven action. Interceptors does this. 

>it all depends on how your domain model works
Sorry, but I don't get how LDM depends on domain model.. I belive by domain 
model you mean, the core 'domain model design' of application. Entities and 
relationships ?

> when you need to put your entity into session because you want to access it 
> across requests, or when you put things into conversation scope. this problem
has nothing to do with wicket. LDM is simply one concrete solution for dealing 
with these kinds of issues.

During most of my past project, I was rarely if ever required to put entities 
into session, most of the time alternatives worked. 
Wicket requires me to put entities into session and so provides LDM. So its 
like a solution to its own need.

I can understand that being a component oriented framework, wicket has lil 
different needs, and thts fine most of time. 
My point was 'there's some overhead involved when working on integration of 
other frameworks'.

Thanks
SN




Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Igor Vaynberg 
To: users@wicket.apache.org
Sent: Wed, 23 December, 2009 2:13:37 AM
Subject: Re: Wicket feedback

On Tue, Dec 22, 2009 at 11:13 AM,   wrote:
> Thanks for clarifying the things,
>
>> show me a framework that makes this easier...
> I think that when I when I was working with Webwork (Struts2 now) I dint need 
> to do any thing else other than specifying spring factory in one of config 
> file. Neither I was forced to use annotations.

so how does webwork know which properties of your actions should be
injected from spring and which from the request or session objects?

> LDMA might have nothing to do with Integration, but from my lil experience, I 
> think that When I want to pass my entity as a model to some components (which 
> might be serialized as in most cases) It wouldnt work with normal models, I 
> will have to manage a separate LDM class for each of that if I don't want 
> lazyloading exceptions.

huh? it all depends on how your domain model works. every application
is different. same applies to other frameworks - eg when you need to
put your entity into session because you want to access it across
requests, or when you put things into conversation scope. this problem
has nothing to do with wicket. LDM is simply one concrete solution for
dealing with these kinds of issues.

-igor

>
>
>
>
>
> Sudhir NimavatSenior software engineer.
> Quick start global PVT LTD.
> Baroda - 390007
> Gujarat, India
>
> Personally I'm always ready to learn, although I do not always like being 
> taught
>
>
>
>
>
> 
> From: Igor Vaynberg 
> To: users@wicket.apache.org
> Sent: Wed, 23 December, 2009 12:03:05 AM
> Subject: Re: Wicket feedback
>
> On Tue, Dec 22, 2009 at 10:20 AM,   wrote:
>> Yes, from my little experience, I just started learning it [Because I feel 
>> it has some thing different to offer]
>>
>>>orly? so what about integrations with hibernate, jdo, jpa, spring,
>> guice, cdi, etc? i guess all those things are a figment of my
>> imagination.
>>
>> As I said it takes comparatively(to some others) more efforts.
>> If I talk about spring, using spring with wicket needs special care, one 
>> will have to take care that he > does not serialize entire containers.
>
> that is taken care for you by the framework. all you have to do is
> install the component injector (1 line of code) and use @SpringBean
> annotations in your pages to inject your dependencies. show me a
> framework that makes this easier...
>
>>I haven't  tried to use hibernate yet (just playing with inmemories) but I 
>>think that I will have to  create LoadableDetachable model of most of my 
>>entities (plz correct me if I am wrong)
>
> LDMs have nothing to do with integration with other frameworks but how
> you want to manage state. in some cases it makes sense not to use LDMs
> f

Re: Wicket feedback

[sudhir543-dev]

> so how does webwork know which properties of your actions should be injected 
> from spring and which from the request or session objects?

- Actions can be configured as spring beans... webwork knows how to get it from 
there, developer decides what dependencies should be managed by spring.
- Action is available in valuestack, for example, when form is submitted, 
webwork can set properties directly on your action or on your model if it is a 
  modal driven action. Interceptors does this. 

>it all depends on how your domain model works
Sorry, but I don't get how LDM depends on domain model.. I belive by domain 
model you mean, the core 'domain model design' of application. Entities and 
relationships ?

> when you need to put your entity into session because you want to access it 
> acrossrequests, or when you put things into conversation scope. this problem
has nothing to do with wicket. LDM is simply one concrete solution for dealing 
with these kinds of issues.

During most of my past project, I was rarely if ever required to put entities 
into session, most of the time alternatives worked. 
Wicket requires me to put entities into session and so provides LDM. So its 
like a solution to its own need.

I can understand that being a component oriented framework, wicket has lil 
different needs, and thts fine most of time. 
My point was 'there's some overhead involved when working on integration of 
other frameworks'.

Thanks
SN




Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Igor Vaynberg 
To: users@wicket.apache.org
Sent: Wed, 23 December, 2009 2:13:37 AM
Subject: Re: Wicket feedback

On Tue, Dec 22, 2009 at 11:13 AM,   wrote:
> Thanks for clarifying the things,
>
>> show me a framework that makes this easier...
> I think that when I when I was working with Webwork (Struts2 now) I dint need 
> to do any thing else other than specifying spring factory in one of config 
> file. Neither I was forced to use annotations.

so how does webwork know which properties of your actions should be
injected from spring and which from the request or session objects?

> LDMA might have nothing to do with Integration, but from my lil experience, I 
> think that When I want to pass my entity as a model to some components (which 
> might be serialized as in most cases) It wouldnt work with normal models, I 
> will have to manage a separate LDM class for each of that if I don't want 
> lazyloading exceptions.

huh? it all depends on how your domain model works. every application
is different. same applies to other frameworks - eg when you need to
put your entity into session because you want to access it across
requests, or when you put things into conversation scope. this problem
has nothing to do with wicket. LDM is simply one concrete solution for
dealing with these kinds of issues.

-igor

>
>
>
>
>
> Sudhir NimavatSenior software engineer.
> Quick start global PVT LTD.
> Baroda - 390007
> Gujarat, India
>
> Personally I'm always ready to learn, although I do not always like being 
> taught
>
>
>
>
>
> 
> From: Igor Vaynberg 
> To: users@wicket.apache.org
> Sent: Wed, 23 December, 2009 12:03:05 AM
> Subject: Re: Wicket feedback
>
> On Tue, Dec 22, 2009 at 10:20 AM,   wrote:
>> Yes, from my little experience, I just started learning it [Because I feel 
>> it has some thing different to offer]
>>
>>>orly? so what about integrations with hibernate, jdo, jpa, spring,
>> guice, cdi, etc? i guess all those things are a figment of my
>> imagination.
>>
>> As I said it takes comparatively(to some others) more efforts.
>> If I talk about spring, using spring with wicket needs special care, one 
>> will have to take care that he > does not serialize entire containers.
>
> that is taken care for you by the framework. all you have to do is
> install the component injector (1 line of code) and use @SpringBean
> annotations in your pages to inject your dependencies. show me a
> framework that makes this easier...
>
>>I haven't  tried to use hibernate yet (just playing with inmemories) but I 
>>think that I will have to  create LoadableDetachable model of most of my 
>>entities (plz correct me if I am wrong)
>
> LDMs have nothing to do with integration with other frameworks but how
> you want to manage state. in some cases it makes sense not to use LDMs
> for hibernate entities.
>
> -igor
>
>
>>
>>
>>
>>
>>
>>
>> Sudhir NimavatSenior software engineer.
>> Quick start global PVT LTD.
>> Baroda - 390007
>> Gujarat, India
>>
>> Personally I'm always ready to learn, although I do not always like being 
>> taught
>>
>>
>>
>>
>>
>> 
>> From: Igor Vaynberg 
>> To: users@wicket.apache.org
>> Sent: Tue, 22 December, 2009 9:46:45 PM
>> Subject: Re: Wicket feedback
>>
>> On Tue, Dec 22, 2009 at 6

Re: resize and crop web images

[Fernando Wermus]

look at london wicket. I think I see something with wicket.

On Tue, Dec 22, 2009 at 11:12 AM, nino martinez wael <
nino.martinez.w...@gmail.com> wrote:

> sure theres a lot, if you want do to fancy image manipulation and
> detection you could use imagemagic. Otherwise just google "java crop"
>
> 2009/12/22 Christoph Grün :
> > Hi,
> >
> > Is there a project/work that allows to resize and crop web images?
> > I would like to show Wikipedia images in a list, each displayed as e.g.,
> > 100*100 px .
> >
> > Thanks a lot,
> > Chris
> >
> >
> > -
> > 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
>
>


-- 
Fernando Wermus.

www.linkedin.com/in/fernandowermus

Re: Groovy 1.7 released with ...

[Ashley Aitken]

Hi Nino (et al.),

I'm not sure, but I think you are referring to Grails using Wicket  
pages (components) written in Java for the presentation layer.   I am  
not talking about Grails.


There have been a couple of projects / attempts to use Groovy to write  
Wicket components and applications but they have been difficult  
because Wicket uses Anonymous Inner Classes a lot, which in the past  
Groovy hasn't supported.


Groovy in general can easily use Java classes (and thus Wicket and  
Java libraries).  This new release means, I believe, its now  
possible / easy  to write a complete Wicket application using the  
Groovy language.


Someone please correct me if I am wrong (which could be quite likely).

Cheers,
Ashley.


On 23/12/2009, at 1:52 AM, nino martinez wael wrote:

AFAIK wicket and Groovy has been possible with grails for a loong  
time..


2009/12/22 Ashley Aitken :


Hi All,

FYI.

Groovy 1.7 has just been released with support for Anonymous Inner  
Classes

and Nested Classes (as well as other new features and enhancements).

For those interested in using Groovy with Wicket this should make  
things

doable now and perhaps simpler than regular Java.



Cheers,
Ashley.

--
Ashley Aitken
Perth, Western Australia
mrhatken at mac dot com
Skype Name: MrHatken (GMT + 8 Hours!)








-
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




--
Ashley Aitken
Perth, Western Australia
Skype/iChat: MrHatken (GMT + 8hrs!)


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [OT a wee bit] Happy Holidays Wicketeers!

[Jens Greven]

Steve Hiller schrieb:

I just want to take this opportunity to thank all the Wicketeers who have been 
very kind
to me over the past couple of years by 1) creating the Wicket framework and 2) 
providing generous
support. The company I work for now has several enterprise-wise apps based on 
Wicket, all of
which are considered true success stories. Once again, thanks and Happy 
Holidays to you all.

Steve




Merry X-Mas, Happy holidays and a very good new year 2010 to everyone in 
this supportive community from Muenster, Germany, too ;-)





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

[OT a wee bit] Happy Holidays Wicketeers!

[Steve Hiller]

I just want to take this opportunity to thank all the Wicketeers who have been 
very kind
to me over the past couple of years by 1) creating the Wicket framework and 2) 
providing generous
support. The company I work for now has several enterprise-wise apps based on 
Wicket, all of
which are considered true success stories. Once again, thanks and Happy 
Holidays to you all.

Steve

jobs

[Jonathan Locke]

not definitely looking yet, but my company was just bought and while that's a 
good thing, it's unclear to me exactly how everything is going to shake out.  
so i'm curious what's going on out there.  i can provide references from some 
of the best in the industry.  you already have a code sample. :)

http://web.me.com/jonathan.locke/JonathanLocke/Resume.html

  jon


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: brix and blogs

[haiko]

Fernando, 

I have written a blog entry on the basic elements of brix. See it here
http://www.cybersnippet.nl/blog/entry/brixcms. In the entry is also a
link to a live brix demo app. Let me know what you think about it.

Greetings, 

Haiko 

On Tue, 2009-12-22 at 18:17 -0200, Fernando Wermus wrote:
> Hi all,
>  I would like to know if there is someone writing about brix in some
> blog. As the info in brix page is poor, I am looking for another way to
> undersand better the cms.
> 
> Thanks in advance.
> 



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket feedback

[Igor Vaynberg]

On Tue, Dec 22, 2009 at 11:13 AM,   wrote:
> Thanks for clarifying the things,
>
>> show me a framework that makes this easier...
> I think that when I when I was working with Webwork (Struts2 now) I dint need 
> to do any thing else other than specifying spring factory in one of config 
> file. Neither I was forced to use annotations.

so how does webwork know which properties of your actions should be
injected from spring and which from the request or session objects?

> LDMA might have nothing to do with Integration, but from my lil experience, I 
> think that When I want to pass my entity as a model to some components (which 
> might be serialized as in most cases) It wouldnt work with normal models, I 
> will have to manage a separate LDM class for each of that if I don't want 
> lazyloading exceptions.

huh? it all depends on how your domain model works. every application
is different. same applies to other frameworks - eg when you need to
put your entity into session because you want to access it across
requests, or when you put things into conversation scope. this problem
has nothing to do with wicket. LDM is simply one concrete solution for
dealing with these kinds of issues.

-igor

>
>
>
>
>
> Sudhir NimavatSenior software engineer.
> Quick start global PVT LTD.
> Baroda - 390007
> Gujarat, India
>
> Personally I'm always ready to learn, although I do not always like being 
> taught
>
>
>
>
>
> 
> From: Igor Vaynberg 
> To: users@wicket.apache.org
> Sent: Wed, 23 December, 2009 12:03:05 AM
> Subject: Re: Wicket feedback
>
> On Tue, Dec 22, 2009 at 10:20 AM,   wrote:
>> Yes, from my little experience, I just started learning it [Because I feel 
>> it has some thing different to offer]
>>
>>>orly? so what about integrations with hibernate, jdo, jpa, spring,
>> guice, cdi, etc? i guess all those things are a figment of my
>> imagination.
>>
>> As I said it takes comparatively(to some others) more efforts.
>> If I talk about spring, using spring with wicket needs special care, one 
>> will have to take care that he > does not serialize entire containers.
>
> that is taken care for you by the framework. all you have to do is
> install the component injector (1 line of code) and use @SpringBean
> annotations in your pages to inject your dependencies. show me a
> framework that makes this easier...
>
>>I haven't  tried to use hibernate yet (just playing with inmemories) but I 
>>think that I will have to  create LoadableDetachable model of most of my 
>>entities (plz correct me if I am wrong)
>
> LDMs have nothing to do with integration with other frameworks but how
> you want to manage state. in some cases it makes sense not to use LDMs
> for hibernate entities.
>
> -igor
>
>
>>
>>
>>
>>
>>
>>
>> Sudhir NimavatSenior software engineer.
>> Quick start global PVT LTD.
>> Baroda - 390007
>> Gujarat, India
>>
>> Personally I'm always ready to learn, although I do not always like being 
>> taught
>>
>>
>>
>>
>>
>> 
>> From: Igor Vaynberg 
>> To: users@wicket.apache.org
>> Sent: Tue, 22 December, 2009 9:46:45 PM
>> Subject: Re: Wicket feedback
>>
>> On Tue, Dec 22, 2009 at 6:21 AM,   wrote:
>>
>> lol
>>
>>> Ajax with wicket is easy.. if you do it the wicket way..  But integration 
>>> with other engines isnt going to be easy.
>>
>>
>> maybe if you have "little" experience you should not be making such
>> sweeping statements. there are projects in wicketstuff and the
>> internets that integrate wicket with jquery, dojo, prototype, ricoh,
>> mootools, etc. and they do so easily, because wicket makes it easy.
>>
>>> Not only Ajax, from my little wicket experience, I would say wicket works 
>>> great in isolation, however integrating it to any other framework would 
>>> take (and it takes) comparatively more efforts.
>>
>> orly? so what about integrations with hibernate, jdo, jpa, spring,
>> guice, cdi, etc? i guess all those things are a figment of my
>> imagination.
>>
>> -igor
>>
>>>
>>>
>>>
>>>
>>> Sudhir NimavatSenior software engineer.
>>> Quick start global PVT LTD.
>>> Baroda - 390007
>>> Gujarat, India
>>>
>>> Personally I'm always ready to learn, although I do not always like being 
>>> taught
>>>
>>>
>>>
>>>
>>>
>>> 
>>> From: Ricardo Mayerhofer 
>>> To: users@wicket.apache.org
>>> Sent: Tue, 22 December, 2009 6:49:02 PM
>>> Subject: Wicket feedback
>>>
>>> Hi all,
>>> We've just finished with success a wicket project for a large online 
>>> retailer. I think wicket is the best framework out there, but as any other 
>>> project there is room for improvement. I will talk about some topics 
>>> bellow, I hope it can help in some way.
>>>
>>> - Separation of corcerns
>>> I think we could get a better separation of concerns if page class were 
>>> focused more in behavior and html were more focused in display (or view).
>>> What I mean is, some times we have components that the main purpose is to 
>>> add beha

brix and blogs

[Fernando Wermus]

Hi all,
 I would like to know if there is someone writing about brix in some
blog. As the info in brix page is poor, I am looking for another way to
undersand better the cms.

Thanks in advance.

-- 
Fernando Wermus.

www.linkedin.com/in/fernandowermus

Re: Wicket feedback

[sudhir543-dev]

Thanks for clarifying the things,

> show me a framework that makes this easier... 
I think that when I when I was working with Webwork (Struts2 now) I dint need 
to do any thing else other than specifying spring factory in one of config 
file. Neither I was forced to use annotations.


LDMA might have nothing to do with Integration, but from my lil experience, I 
think that When I want to pass my entity as a model to some components (which 
might be serialized as in most cases) It wouldnt work with normal models, I 
will have to manage a separate LDM class for each of that if I don't want 
lazyloading exceptions. 


 
  

Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Igor Vaynberg 
To: users@wicket.apache.org
Sent: Wed, 23 December, 2009 12:03:05 AM
Subject: Re: Wicket feedback

On Tue, Dec 22, 2009 at 10:20 AM,   wrote:
> Yes, from my little experience, I just started learning it [Because I feel it 
> has some thing different to offer]
>
>>orly? so what about integrations with hibernate, jdo, jpa, spring,
> guice, cdi, etc? i guess all those things are a figment of my
> imagination.
>
> As I said it takes comparatively(to some others) more efforts.
> If I talk about spring, using spring with wicket needs special care, one will 
> have to take care that he > does not serialize entire containers.

that is taken care for you by the framework. all you have to do is
install the component injector (1 line of code) and use @SpringBean
annotations in your pages to inject your dependencies. show me a
framework that makes this easier...

>I haven't  tried to use hibernate yet (just playing with inmemories) but I 
>think that I will have to  create LoadableDetachable model of most of my 
>entities (plz correct me if I am wrong)

LDMs have nothing to do with integration with other frameworks but how
you want to manage state. in some cases it makes sense not to use LDMs
for hibernate entities.

-igor


>
>
>
>
>
>
> Sudhir NimavatSenior software engineer.
> Quick start global PVT LTD.
> Baroda - 390007
> Gujarat, India
>
> Personally I'm always ready to learn, although I do not always like being 
> taught
>
>
>
>
>
> 
> From: Igor Vaynberg 
> To: users@wicket.apache.org
> Sent: Tue, 22 December, 2009 9:46:45 PM
> Subject: Re: Wicket feedback
>
> On Tue, Dec 22, 2009 at 6:21 AM,   wrote:
>
> lol
>
>> Ajax with wicket is easy.. if you do it the wicket way..  But integration 
>> with other engines isnt going to be easy.
>
>
> maybe if you have "little" experience you should not be making such
> sweeping statements. there are projects in wicketstuff and the
> internets that integrate wicket with jquery, dojo, prototype, ricoh,
> mootools, etc. and they do so easily, because wicket makes it easy.
>
>> Not only Ajax, from my little wicket experience, I would say wicket works 
>> great in isolation, however integrating it to any other framework would take 
>> (and it takes) comparatively more efforts.
>
> orly? so what about integrations with hibernate, jdo, jpa, spring,
> guice, cdi, etc? i guess all those things are a figment of my
> imagination.
>
> -igor
>
>>
>>
>>
>>
>> Sudhir NimavatSenior software engineer.
>> Quick start global PVT LTD.
>> Baroda - 390007
>> Gujarat, India
>>
>> Personally I'm always ready to learn, although I do not always like being 
>> taught
>>
>>
>>
>>
>>
>> 
>> From: Ricardo Mayerhofer 
>> To: users@wicket.apache.org
>> Sent: Tue, 22 December, 2009 6:49:02 PM
>> Subject: Wicket feedback
>>
>> Hi all,
>> We've just finished with success a wicket project for a large online 
>> retailer. I think wicket is the best framework out there, but as any other 
>> project there is room for improvement. I will talk about some topics bellow, 
>> I hope it can help in some way.
>>
>> - Separation of corcerns
>> I think we could get a better separation of concerns if page class were 
>> focused more in behavior and html were more focused in display (or view).
>> What I mean is, some times we have components that the main purpose is to 
>> add behavior, and we have to add extra markup just to satisfy wicket 1:1 
>> mapping. Take CheckGroup for exaple, it is a component focused on behavior, 
>> even though we have to add a reference to it in HTML.
>>
>> When creating composite input fields (like date), the usual way is to create 
>> a panel even if you are not interested in reusability. A interesting aproach 
>> is to insert a hidden text field in HTML mapped to a component that controls 
>> other components input. It makes easier to integrate with designer and to 
>> preview in browser. If we didn't have this limitation the hidden input would 
>> not be necessary and the development of behavior focused components would be 
>> easier.
>>
>> One thing that bothers me

Re: Wicket feedback

[Igor Vaynberg]

On Tue, Dec 22, 2009 at 10:20 AM,   wrote:
> Yes, from my little experience, I just started learning it [Because I feel it 
> has some thing different to offer]
>
>>orly? so what about integrations with hibernate, jdo, jpa, spring,
> guice, cdi, etc? i guess all those things are a figment of my
> imagination.
>
> As I said it takes comparatively(to some others) more efforts.
> If I talk about spring, using spring with wicket needs special care, one will 
> have to take care that he > does not serialize entire containers.

that is taken care for you by the framework. all you have to do is
install the component injector (1 line of code) and use @SpringBean
annotations in your pages to inject your dependencies. show me a
framework that makes this easier...

>I haven't  tried to use hibernate yet (just playing with inmemories) but I 
>think that I will have to  create LoadableDetachable model of most of my 
>entities (plz correct me if I am wrong)

LDMs have nothing to do with integration with other frameworks but how
you want to manage state. in some cases it makes sense not to use LDMs
for hibernate entities.

-igor


>
>
>
>
>
>
> Sudhir NimavatSenior software engineer.
> Quick start global PVT LTD.
> Baroda - 390007
> Gujarat, India
>
> Personally I'm always ready to learn, although I do not always like being 
> taught
>
>
>
>
>
> 
> From: Igor Vaynberg 
> To: users@wicket.apache.org
> Sent: Tue, 22 December, 2009 9:46:45 PM
> Subject: Re: Wicket feedback
>
> On Tue, Dec 22, 2009 at 6:21 AM,   wrote:
>
> lol
>
>> Ajax with wicket is easy.. if you do it the wicket way..  But integration 
>> with other engines isnt going to be easy.
>
>
> maybe if you have "little" experience you should not be making such
> sweeping statements. there are projects in wicketstuff and the
> internets that integrate wicket with jquery, dojo, prototype, ricoh,
> mootools, etc. and they do so easily, because wicket makes it easy.
>
>> Not only Ajax, from my little wicket experience, I would say wicket works 
>> great in isolation, however integrating it to any other framework would take 
>> (and it takes) comparatively more efforts.
>
> orly? so what about integrations with hibernate, jdo, jpa, spring,
> guice, cdi, etc? i guess all those things are a figment of my
> imagination.
>
> -igor
>
>>
>>
>>
>>
>> Sudhir NimavatSenior software engineer.
>> Quick start global PVT LTD.
>> Baroda - 390007
>> Gujarat, India
>>
>> Personally I'm always ready to learn, although I do not always like being 
>> taught
>>
>>
>>
>>
>>
>> 
>> From: Ricardo Mayerhofer 
>> To: users@wicket.apache.org
>> Sent: Tue, 22 December, 2009 6:49:02 PM
>> Subject: Wicket feedback
>>
>> Hi all,
>> We've just finished with success a wicket project for a large online 
>> retailer. I think wicket is the best framework out there, but as any other 
>> project there is room for improvement. I will talk about some topics bellow, 
>> I hope it can help in some way.
>>
>> - Separation of corcerns
>> I think we could get a better separation of concerns if page class were 
>> focused more in behavior and html were more focused in display (or view).
>> What I mean is, some times we have components that the main purpose is to 
>> add behavior, and we have to add extra markup just to satisfy wicket 1:1 
>> mapping. Take CheckGroup for exaple, it is a component focused on behavior, 
>> even though we have to add a reference to it in HTML.
>>
>> When creating composite input fields (like date), the usual way is to create 
>> a panel even if you are not interested in reusability. A interesting aproach 
>> is to insert a hidden text field in HTML mapped to a component that controls 
>> other components input. It makes easier to integrate with designer and to 
>> preview in browser. If we didn't have this limitation the hidden input would 
>> not be necessary and the development of behavior focused components would be 
>> easier.
>>
>> One thing that bothers me is when our designer move things around in HTML 
>> and we get "added a component in code but forgot to reference it in the 
>> markup" error, because of component hierarchy. Html tags position is a view 
>> problem not a behavior problem, so why bother in java?
>>
>> Another issue, is when we want to change the class of a div, for example, 
>> and have to change our whole page hierarchy in java, just to manipulate that 
>> tag.
>>
>> So I think a hierarchy more focused on components behavior (for example 
>> taking care of inherited models and inputs), rather than tags position in 
>> HTML would be better. This would make wicket more flexible and easier to 
>> work with.
>>
>> - Too many finals modifiers
>> It's hard for a API or framework designer to foresee all uses and unxepected 
>> situations its users may face in day to day development. Final modifiers 
>> places a additional challenge when facing these situations. In project were 
>> deadlines are in pla

Re: Wicket feedback

[sudhir543-dev]

Yes, from my little experience, I just started learning it [Because I feel it 
has some thing different to offer]

>orly? so what about integrations with hibernate, jdo, jpa, spring,
guice, cdi, etc? i guess all those things are a figment of my
imagination.

As I said it takes comparatively(to some others) more efforts. 
If I talk about spring, using spring with wicket needs special care, one will 
have to take care that he does not serialize entire containers. I haven't  
tried to use hibernate yet (just playing with inmemories) but I think that I 
will have to create LoadableDetachable model of most of my entities (plz 
correct me if I am wrong)



 
  

Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Igor Vaynberg 
To: users@wicket.apache.org
Sent: Tue, 22 December, 2009 9:46:45 PM
Subject: Re: Wicket feedback

On Tue, Dec 22, 2009 at 6:21 AM,   wrote:

lol

> Ajax with wicket is easy.. if you do it the wicket way..  But integration 
> with other engines isnt going to be easy.


maybe if you have "little" experience you should not be making such
sweeping statements. there are projects in wicketstuff and the
internets that integrate wicket with jquery, dojo, prototype, ricoh,
mootools, etc. and they do so easily, because wicket makes it easy.

> Not only Ajax, from my little wicket experience, I would say wicket works 
> great in isolation, however integrating it to any other framework would take 
> (and it takes) comparatively more efforts.

orly? so what about integrations with hibernate, jdo, jpa, spring,
guice, cdi, etc? i guess all those things are a figment of my
imagination.

-igor

>
>
>
>
> Sudhir NimavatSenior software engineer.
> Quick start global PVT LTD.
> Baroda - 390007
> Gujarat, India
>
> Personally I'm always ready to learn, although I do not always like being 
> taught
>
>
>
>
>
> 
> From: Ricardo Mayerhofer 
> To: users@wicket.apache.org
> Sent: Tue, 22 December, 2009 6:49:02 PM
> Subject: Wicket feedback
>
> Hi all,
> We've just finished with success a wicket project for a large online 
> retailer. I think wicket is the best framework out there, but as any other 
> project there is room for improvement. I will talk about some topics bellow, 
> I hope it can help in some way.
>
> - Separation of corcerns
> I think we could get a better separation of concerns if page class were 
> focused more in behavior and html were more focused in display (or view).
> What I mean is, some times we have components that the main purpose is to add 
> behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping. 
> Take CheckGroup for exaple, it is a component focused on behavior, even 
> though we have to add a reference to it in HTML.
>
> When creating composite input fields (like date), the usual way is to create 
> a panel even if you are not interested in reusability. A interesting aproach 
> is to insert a hidden text field in HTML mapped to a component that controls 
> other components input. It makes easier to integrate with designer and to 
> preview in browser. If we didn't have this limitation the hidden input would 
> not be necessary and the development of behavior focused components would be 
> easier.
>
> One thing that bothers me is when our designer move things around in HTML and 
> we get "added a component in code but forgot to reference it in the markup" 
> error, because of component hierarchy. Html tags position is a view problem 
> not a behavior problem, so why bother in java?
>
> Another issue, is when we want to change the class of a div, for example, and 
> have to change our whole page hierarchy in java, just to manipulate that tag.
>
> So I think a hierarchy more focused on components behavior (for example 
> taking care of inherited models and inputs), rather than tags position in 
> HTML would be better. This would make wicket more flexible and easier to work 
> with.
>
> - Too many finals modifiers
> It's hard for a API or framework designer to foresee all uses and unxepected 
> situations its users may face in day to day development. Final modifiers 
> places a additional challenge when facing these situations. In project were 
> deadlines are in place, there is little room for submiting a request and 
> waiting for a new version to be released. Furthermore, unfortunately, it's 
> not possible to mock final methods making it harder sometimes to test wicket 
> related classes/components. What we had to do internally, is to have our own 
> version of wicket, mainly to remove final modifiers when necessary, a clear 
> violation of open/closed principle.
>
> - Ajax
> Wicket offers no stateless ajax and often changes HTML id, which makes harder 
> to integrate with a 3rd party ajax framework. Is there any hope for 
> constructor change?
>
> Pleas

Re: datatable delete

[Sam Barrow]

its the dataprovider, i was supplying it with a collection of rows in
the constructor, rather than getting the data fresh inside the
dataprovider. thanks!

On Tue, 2009-12-22 at 10:05 -0800, Igor Vaynberg wrote:
> then check your delete logic, or set a breakpoint in your dataprovider
> and see why the row entity is still being retrieved.
> 
> -igor
> 
> On Tue, Dec 22, 2009 at 10:03 AM, Sam Barrow  wrote:
> > that's how i thought it work, but it doesnt at all for me, ive tried so
> > many times. i have to re-click the link to the page, even a refresh with
> > the f5 key doesnt get rid of the missing row.
> >
> > On Tue, 2009-12-22 at 09:59 -0800, Igor Vaynberg wrote:
> >> the table refreshes on every render, so as long as your idataprovider
> >> does not retrieve the row after you delete it it will be gone.
> >>
> >> sometimes it pays to simply try and see, most things will work as expected.
> >>
> >> -igor
> >>
> >> On Tue, Dec 22, 2009 at 9:55 AM, Sam Barrow  wrote:
> >> > if i have a link in a row of a datatable that deletes an item, how do i
> >> > make that row disappear? or just refresh the whole table?
> >> >
> >> >
> >> > -
> >> > 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
> >>
> >
> >
> >
> > -
> > 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
> 



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: datatable delete

[Igor Vaynberg]

then check your delete logic, or set a breakpoint in your dataprovider
and see why the row entity is still being retrieved.

-igor

On Tue, Dec 22, 2009 at 10:03 AM, Sam Barrow  wrote:
> that's how i thought it work, but it doesnt at all for me, ive tried so
> many times. i have to re-click the link to the page, even a refresh with
> the f5 key doesnt get rid of the missing row.
>
> On Tue, 2009-12-22 at 09:59 -0800, Igor Vaynberg wrote:
>> the table refreshes on every render, so as long as your idataprovider
>> does not retrieve the row after you delete it it will be gone.
>>
>> sometimes it pays to simply try and see, most things will work as expected.
>>
>> -igor
>>
>> On Tue, Dec 22, 2009 at 9:55 AM, Sam Barrow  wrote:
>> > if i have a link in a row of a datatable that deletes an item, how do i
>> > make that row disappear? or just refresh the whole table?
>> >
>> >
>> > -
>> > 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
>>
>
>
>
> -
> 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: datatable delete

[Sam Barrow]

that's how i thought it work, but it doesnt at all for me, ive tried so
many times. i have to re-click the link to the page, even a refresh with
the f5 key doesnt get rid of the missing row.

On Tue, 2009-12-22 at 09:59 -0800, Igor Vaynberg wrote:
> the table refreshes on every render, so as long as your idataprovider
> does not retrieve the row after you delete it it will be gone.
> 
> sometimes it pays to simply try and see, most things will work as expected.
> 
> -igor
> 
> On Tue, Dec 22, 2009 at 9:55 AM, Sam Barrow  wrote:
> > if i have a link in a row of a datatable that deletes an item, how do i
> > make that row disappear? or just refresh the whole table?
> >
> >
> > -
> > 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
> 



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: datatable delete

[Igor Vaynberg]

the table refreshes on every render, so as long as your idataprovider
does not retrieve the row after you delete it it will be gone.

sometimes it pays to simply try and see, most things will work as expected.

-igor

On Tue, Dec 22, 2009 at 9:55 AM, Sam Barrow  wrote:
> if i have a link in a row of a datatable that deletes an item, how do i
> make that row disappear? or just refresh the whole table?
>
>
> -
> 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

datatable delete

[Sam Barrow]

if i have a link in a row of a datatable that deletes an item, how do i
make that row disappear? or just refresh the whole table?


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Groovy 1.7 released with ...

[nino martinez wael]

AFAIK wicket and Groovy has been possible with grails for a loong time..

2009/12/22 Ashley Aitken :
>
> Hi All,
>
> FYI.
>
> Groovy 1.7 has just been released with support for Anonymous Inner Classes
> and Nested Classes (as well as other new features and enhancements).
>
> For those interested in using Groovy with Wicket this should make things
> doable now and perhaps simpler than regular Java.
>
> 
>
> Cheers,
> Ashley.
>
> --
> Ashley Aitken
> Perth, Western Australia
> mrhatken at mac dot com
> Skype Name: MrHatken (GMT + 8 Hours!)
>
>
>
>
>
>
>
>
> -
> 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: Announcement: Annotation-based Mounting of Resources

[sfussenegger]

Hi James,

Sorry for the late response. I would personally say: no, it isn't saving
that much. I use these "few helper methods" that are also part of the
project. However, some people requested support for annotations and like
using it. Additionally, it fits pretty well with wicketstuff-annotations'
mounting of pages (which I neither use myself).

So at the the, it's a live and let live thing :) 

Cheers, Stefan


James Carman-3 wrote:
> 
> Is this annotation-based approach really saving that much?  It seems
> to me that a few helper methods would do just as well.
> 
> On Wed, Dec 2, 2009 at 1:51 AM, Toscano  wrote:
>>
>> Hi again,
>>
>> First of all, thank you for your time and dedication with this project, I
>> think is really useful and interesting.
>>
>> I just can't have it working and I don't know the reason, I would really
>> appreciate if you can spend a few minutes trying to help me if you don't
>> mind.
>>
>> I'm using Wicket 1.4.3 and the annotations approach. My javascript files
>> are
>> all in /js not in the java folder.
>>
>> So what I do is go the init() of my webapp and write this:
>>
>>        ResourceMount mount = new ResourceMount();
>>        ResourceMount.mountAnnotatedPackageResources("/js",
>> "MyApplication.Page", this, mount);
>>
>> Then I go to MyApplication.Page.HomePage and write this annotation:
>> @JsContribution("jquery.min.js")
>>
>> When I try to run the application, I get this error:
>>  failed to mount resource ('/js/all.js')
>> WicketRuntimeException: js/all.js is already mounted for
>> SharedResourceEncoder
>>
>> I'm sure I'm understanding something wrong... hope you can help me...
>>
>> Thank you again,
>> Oskar
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> sfussenegger wrote:
>>>
>>> Today, I’m happy to announce the availability of annotation-based
>>> mounting and merging of resources in wicketstuff-merged-resources
>>> (version 3.0-SNAPSHOT for Wicket 1.4, version 2.1-SNAPSHOT for Wicket
>>> 1.3). In order to mount resources, all that’s needed is adding
>>> annotations to component classes:
>>>
>>> @JsContribution
>>> @CssContribution(media = "print")
>>> @ResourceContribution(value = "accept.png", path = "/img/accept.png")
>>> public class PanelOne extends Panel {
>>>
>>>      public PanelOne(String id) {
>>>          super(id);
>>>          // ...
>>>      }
>>> }
>>>
>>> As an added benefit, you’ll get all the other features of
>>> wicketstuff-merged-resources:
>>>
>>> merging of multiple files into one for less HTTP requests
>>> adding of versions to resource paths for aggressive caching
>>> pre-processing of resources (e.g. replacing colors in CSS files)
>>> optionally uploading them to Amazon Cloudfront (well, at least you can
>>> expect this feature soon – we are using it already)
>>> So you will speed up rendering of your pages while simplifying and
>>> reducing your code (there’s no need to merge, mount or add
>>> HeaderContributors manually anymore)!
>>>
>>> More on our blog ...
>>> http://techblog.molindo.at/2009/10/wicket-annotation-based-mounting-of-resources.html
>>>
>>> ... and Wicket Stuff Wiki:
>>> http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-merged-resources
>>>
>>> Cheers
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>> -
>>> Stefan Fussenegger
>>>
>>> Wicket:
>>> wicketstuff-merged-resources
>>> Wicket on techblog.molindo.at
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Announcement%3A-Annotation-based-Mounting-of-Resources-tp25886703p26604363.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> 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
> 
> 
> 


-
Stefan Fussenegger

Wicket:
http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-merged-resources
wicketstuff-merged-resources 
http://techblog.molindo.at/ Wicket on techblog.molindo.at 
-- 
View this message in context: 
http://old.nabble.com/Announcement%3A-Annotation-based-Mounting-of-Resources-tp25886703p26891019.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket feedback

[Igor Vaynberg]

On Tue, Dec 22, 2009 at 5:19 AM, Ricardo Mayerhofer
 wrote:
> Hi all,
> We've just finished with success a wicket project for a large online
> retailer. I think wicket is the best framework out there, but as any other
> project there is room for improvement. I will talk about some topics bellow,
> I hope it can help in some way.
>
> - Separation of corcerns
> I think we could get a better separation of concerns if page class were
> focused more in behavior and html were more focused in display (or view).
> What I mean is, some times we have components that the main purpose is to
> add behavior, and we have to add extra markup just to satisfy wicket 1:1
> mapping. Take CheckGroup for exaple, it is a component focused on behavior,
> even though we have to add a reference to it in HTML.

a redesigned CheckGroup is welcome, but that component is the
exception and not the rule.

> When creating composite input fields (like date), the usual way is to create
> a panel even if you are not interested in reusability. A interesting aproach
> is to insert a hidden text field in HTML mapped to a component that controls
> other components input. It makes easier to integrate with designer and to
> preview in browser. If we didn't have this limitation the hidden input would
> not be necessary and the development of behavior focused components would be
> easier.

i dont really understand this..the usual way would be to extend a
FormComponentPanel, not a Panel. are you saying that because the Panel
derivatives are just a  in the markup it makes it difficult for
the designers?

> One thing that bothers me is when our designer move things around in HTML
> and we get "added a component in code but forgot to reference it in the
> markup" error, because of component hierarchy. Html tags position is a view
> problem not a behavior problem, so why bother in java?

it *is* a behavior problem. markup is what drives the rendering order
so if you move things around and change the nesting order of
components then you can have a component that is a child of another
render *before* the parent which will cause things to go seriously out
of whack.

in my company the designers understand that they cannot change the
nesting of tags with wicket:id attributes, it took an hour to explain
it to them, and we have not had any problems since. in practice, there
is no need to do that often anyways...


> Another issue, is when we want to change the class of a div, for example,
> and have to change our whole page hierarchy in java, just to manipulate that
> tag.

you dont have to change the hierarchy, just make the component
attached to that div a "transparent resolver" by overriding
isTransparentResolver() and returning true.

> So I think a hierarchy more focused on components behavior (for example
> taking care of inherited models and inputs), rather than tags position in
> HTML would be better. This would make wicket more flexible and easier to
> work with.

once again, this is only a problem when you change the *nesting* of
components. if a component can be safely moved outside the parent,
then why is there a nesting to begin with? why arent the two
components siblings? the *nesting* is usually there *because* there is
a functional requirement.

here is a simple usecase:

webmarkupcontainer admin=new webmarkupcontainer("admin") { isvisible()
{ return user.isadmin(); }};
admin.add(new link("delete") {...});

the code is pretty much self-explanatory, now the designer takes the
delete link and moves it ouside the wicket:id="admin" tag. in your
vision this would work, but now the designer has completely
circumvented security the developer has put into place.

> - Too many finals modifiers
> It's hard for a API or framework designer to foresee all uses and unxepected
> situations its users may face in day to day development. Final modifiers
> places a additional challenge when facing these situations. In project were
> deadlines are in place, there is little room for submiting a request and
> waiting for a new version to be released. Furthermore, unfortunately, it's
> not possible to mock final methods making it harder sometimes to test wicket
> related classes/components. What we had to do internally, is to have our own
> version of wicket, mainly to remove final modifiers when necessary, a clear
> violation of open/closed principle.

there is a trade off here. the final modifiers allow us to change
things below without breaking the api because final methods do not
expose a contract. when we make a code change inside a final method we
do not have to think about all the users out there who might have
potentially overridden the method in their apps and we have to make
whatever change backwards-compatible.

in short, the upgrade path with final methods looks like this:

1.4.0,1.4.1,...,1.4.8,1.4.9

and the path without final methods would look like this:

1.4.0,1.4.1,1.5.0 (api break),1.5.1, 1.6.0 (api break), 1.7.0 (api break)

and because we are chan

Re: Wicket feedback

[Peter Thomas]

On Tue, Dec 22, 2009 at 7:51 PM,  wrote:

> Ajax with wicket is easy.. if you do it the wicket way..  But integration
> with other engines isnt going to be easy.
>
>
IMHO integration with other engines is actually quite easy, and certainly
far easier than other frameworks, see this:

http://ptrthomas.wordpress.com/2009/08/12/wicket-tutorial-yui-autocomplete-using-json-and-ajax/

in response to the OP who said:

- Ajax
> Wicket offers no stateless ajax and often changes HTML id, which makes
> harder to integrate with a 3rd party ajax framework. Is there any hope for
> constructor change?
>

I haven't found this a problem in practice, maybe a smarter use of
getMarkupId() is the answer.  BTW someone wrote a patch [1] to have stable
markup id-s, it was discussed on the list recently [2]:

[1]
http://blogs.onehippo.org/arthur/2009/02/hippoecm_integration_testing_w.html
[2]
http://old.nabble.com/Hippo%27s-patch-for-wicket-ids-ts25901638.html#a25901638

- Peter


> Not only Ajax, from my little wicket experience, I would say wicket works
> great in isolation, however integrating it to any other framework would take
> (and it takes) comparatively more efforts.
>
>
>
>
> Sudhir NimavatSenior software engineer.
> Quick start global PVT LTD.
> Baroda - 390007
> Gujarat, India
>
> Personally I'm always ready to learn, although I do not always like being
> taught
>
>
>
>
>
> 
> From: Ricardo Mayerhofer 
> To: users@wicket.apache.org
> Sent: Tue, 22 December, 2009 6:49:02 PM
> Subject: Wicket feedback
>
> Hi all,
> We've just finished with success a wicket project for a large online
> retailer. I think wicket is the best framework out there, but as any other
> project there is room for improvement. I will talk about some topics bellow,
> I hope it can help in some way.
>
> - Separation of corcerns
> I think we could get a better separation of concerns if page class were
> focused more in behavior and html were more focused in display (or view).
> What I mean is, some times we have components that the main purpose is to
> add behavior, and we have to add extra markup just to satisfy wicket 1:1
> mapping. Take CheckGroup for exaple, it is a component focused on behavior,
> even though we have to add a reference to it in HTML.
>
> When creating composite input fields (like date), the usual way is to
> create a panel even if you are not interested in reusability. A interesting
> aproach is to insert a hidden text field in HTML mapped to a component that
> controls other components input. It makes easier to integrate with designer
> and to preview in browser. If we didn't have this limitation the hidden
> input would not be necessary and the development of behavior focused
> components would be easier.
>
> One thing that bothers me is when our designer move things around in HTML
> and we get "added a component in code but forgot to reference it in the
> markup" error, because of component hierarchy. Html tags position is a view
> problem not a behavior problem, so why bother in java?
>
> Another issue, is when we want to change the class of a div, for example,
> and have to change our whole page hierarchy in java, just to manipulate that
> tag.
>
> So I think a hierarchy more focused on components behavior (for example
> taking care of inherited models and inputs), rather than tags position in
> HTML would be better. This would make wicket more flexible and easier to
> work with.
>
> - Too many finals modifiers
> It's hard for a API or framework designer to foresee all uses and
> unxepected situations its users may face in day to day development. Final
> modifiers places a additional challenge when facing these situations. In
> project were deadlines are in place, there is little room for submiting a
> request and waiting for a new version to be released. Furthermore,
> unfortunately, it's not possible to mock final methods making it harder
> sometimes to test wicket related classes/components. What we had to do
> internally, is to have our own version of wicket, mainly to remove final
> modifiers when necessary, a clear violation of open/closed principle.
>
> - Ajax
> Wicket offers no stateless ajax and often changes HTML id, which makes
> harder to integrate with a 3rd party ajax framework. Is there any hope for
> constructor change?
>
> Please let me know your thoughts, keep up the good work.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>  The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.
> http://in.yahoo.com/
>

Re: Wicket feedback

[Igor Vaynberg]

On Tue, Dec 22, 2009 at 6:21 AM,   wrote:

lol

> Ajax with wicket is easy.. if you do it the wicket way..  But integration 
> with other engines isnt going to be easy.


maybe if you have "little" experience you should not be making such
sweeping statements. there are projects in wicketstuff and the
internets that integrate wicket with jquery, dojo, prototype, ricoh,
mootools, etc. and they do so easily, because wicket makes it easy.

> Not only Ajax, from my little wicket experience, I would say wicket works 
> great in isolation, however integrating it to any other framework would take 
> (and it takes) comparatively more efforts.

orly? so what about integrations with hibernate, jdo, jpa, spring,
guice, cdi, etc? i guess all those things are a figment of my
imagination.

-igor

>
>
>
>
> Sudhir NimavatSenior software engineer.
> Quick start global PVT LTD.
> Baroda - 390007
> Gujarat, India
>
> Personally I'm always ready to learn, although I do not always like being 
> taught
>
>
>
>
>
> 
> From: Ricardo Mayerhofer 
> To: users@wicket.apache.org
> Sent: Tue, 22 December, 2009 6:49:02 PM
> Subject: Wicket feedback
>
> Hi all,
> We've just finished with success a wicket project for a large online 
> retailer. I think wicket is the best framework out there, but as any other 
> project there is room for improvement. I will talk about some topics bellow, 
> I hope it can help in some way.
>
> - Separation of corcerns
> I think we could get a better separation of concerns if page class were 
> focused more in behavior and html were more focused in display (or view).
> What I mean is, some times we have components that the main purpose is to add 
> behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping. 
> Take CheckGroup for exaple, it is a component focused on behavior, even 
> though we have to add a reference to it in HTML.
>
> When creating composite input fields (like date), the usual way is to create 
> a panel even if you are not interested in reusability. A interesting aproach 
> is to insert a hidden text field in HTML mapped to a component that controls 
> other components input. It makes easier to integrate with designer and to 
> preview in browser. If we didn't have this limitation the hidden input would 
> not be necessary and the development of behavior focused components would be 
> easier.
>
> One thing that bothers me is when our designer move things around in HTML and 
> we get "added a component in code but forgot to reference it in the markup" 
> error, because of component hierarchy. Html tags position is a view problem 
> not a behavior problem, so why bother in java?
>
> Another issue, is when we want to change the class of a div, for example, and 
> have to change our whole page hierarchy in java, just to manipulate that tag.
>
> So I think a hierarchy more focused on components behavior (for example 
> taking care of inherited models and inputs), rather than tags position in 
> HTML would be better. This would make wicket more flexible and easier to work 
> with.
>
> - Too many finals modifiers
> It's hard for a API or framework designer to foresee all uses and unxepected 
> situations its users may face in day to day development. Final modifiers 
> places a additional challenge when facing these situations. In project were 
> deadlines are in place, there is little room for submiting a request and 
> waiting for a new version to be released. Furthermore, unfortunately, it's 
> not possible to mock final methods making it harder sometimes to test wicket 
> related classes/components. What we had to do internally, is to have our own 
> version of wicket, mainly to remove final modifiers when necessary, a clear 
> violation of open/closed principle.
>
> - Ajax
> Wicket offers no stateless ajax and often changes HTML id, which makes harder 
> to integrate with a 3rd party ajax framework. Is there any hope for 
> constructor change?
>
> Please let me know your thoughts, keep up the good work.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. 
> http://in.yahoo.com/

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Groovy 1.7 released with ...

[Ashley Aitken]

Hi All,

FYI.

Groovy 1.7 has just been released with support for Anonymous Inner  
Classes and Nested Classes (as well as other new features and  
enhancements).


For those interested in using Groovy with Wicket this should make  
things doable now and perhaps simpler than regular Java.




Cheers,
Ashley.

--
Ashley Aitken
Perth, Western Australia
mrhatken at mac dot com
Skype Name: MrHatken (GMT + 8 Hours!)








-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: @RequireHttps - forms misbehaving

[VGJ]

My "redirect" method isn't overriding anything, it's just there to provide a
shortcut to an external redirect, should I need it.  Could it still be doing
some damage, somehow?

I was using bookmarkable pages just before switching to Hybrids, at the same
time I started using @RequireHttps, so they did work just fine.

On Mon, Dec 21, 2009 at 4:51 PM, Jason Lea  wrote:

> yay!
>
> But it is odd if setRedirect(true) didn't work when using a page instance.
>  I wonder if the there is an issue with HybridUrlCodingStrategy and
> RequireHttps... can you mount the page you redirect to using a simple
> bookmarkable page and see if it works?
>
> I also noticed you have a method on your BasePage class called
> redirect(url) that disables wicket redirect... does that get called when you
> use setRedirect(true)?
>
>
>
> VGJ wrote:
>
>> Jason...excellent!  setResponsePage(UserAccount.class) did the trick!
>> Thanks!  Using setRedirect(true) didn't have any effect however.  I had to
>> redirect to the page class rather than a new instance of it.
>>
>> This works for me right now...but what happens when I'd like to pass
>> parameters into the constructor of the page I'm redirecting to?
>>
>> -v
>>
>>
> --
> Jason Lea
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Adding components to page (dynamically)

[bgooren]

Ok, so when you say "I need to add more than 1 window", do you mean that the
type of window can differ, or that you want to add multiple windows at once?

In the first case (1 window), you could go for:
final WebMarkupContainer hook = new WebMarkupContainer("win1");
hook.setOutputMarkupId( true );
hook.setOutputMarkupPlaceholderTag( true );
m.add( hook );
and then in onClick( AjaxRequestTarget ) you call m.addOrReplace( window )
and add the window to the AjaxRequestTarget;

In the latter case (multiple windows), you could go for a RepeatingView;
you'll need to put it in a WebMarkupContainer with setOutputMarkupId to true
since you cannot refresh a RepeatingView itself through AJAX. You can (re-)
populate the RepeatingView manually in the onClick( AjaxRequestHandler )
method and add it so it get's re-rendered.


marioosh.net wrote:
> 
> 
> bgooren wrote:
>> 
>> Well, you need to have some html in the container with wicket:id="win1"
>> for your code to work. Wicket is (correctly) complaining that it cannot
>> locate html for your component. What kind of component is Window? (it's
>> not a standard wicket component)
>> 
> 
> Window is simple:
> 
> public class Window extends Panel {
> ...
> }
> 
>  xmlns:wicket="http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
>   ...
> 
> 
> When i add containser with wicket:id="win1" to template, i need to add
> component too, but i need add component after click button. And i need to
> add more then one window.
> 

-- 
View this message in context: 
http://old.nabble.com/Adding-components-to-page-%28dynamically%29-tp26886670p26889863.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket 1.4-rc6 Swarm

[Olivier Bourgeois]

Is there any news regarding a release of Swarm 1.4 ? Because there's still
only the 1.4 snapshots in the repository.

For information, I'm currently using it with Wicket 1.4.3 and got no problem
so far : page security and component conditional rendering works fine.

2009/7/10 Luca Provenzani 

> this is a very good new!
>
> thank you a lot!
>
> Luca
>
> 2009/7/9 Olger Warnier 
>
> > Hi Igor / List,
> >
> > Thanks for the trust.
> >
> > The wicket-security project trunk found at
> >
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-securityis
> > now compatible with wicket 1.4 RC6.
> > If you have issues or comments, please let me know.
> >
> > I am not aware of your release rules, if you have a pointer, I could
> check
> > if it is possibe to get it towards a release along with the wicket 1.4
> > release.
> >
> > Kind Regards,
> >
> > Olger
>

Re: Adding components to page (dynamically)

[marioosh.net]

bgooren wrote:
> 
> Well, you need to have some html in the container with wicket:id="win1"
> for your code to work. Wicket is (correctly) complaining that it cannot
> locate html for your component. What kind of component is Window? (it's
> not a standard wicket component)
> 

Window is simple:

public class Window extends Panel {
...
}

http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd";>
...



-- 
View this message in context: 
http://old.nabble.com/Adding-components-to-page-%28dynamically%29-tp26886670p26889247.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket feedback

[sudhir543-dev]

Ajax with wicket is easy.. if you do it the wicket way..  But integration with 
other engines isnt going to be easy.

Not only Ajax, from my little wicket experience, I would say wicket works great 
in isolation, however integrating it to any other framework would take (and it 
takes) comparatively more efforts.

 
  

Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Ricardo Mayerhofer 
To: users@wicket.apache.org
Sent: Tue, 22 December, 2009 6:49:02 PM
Subject: Wicket feedback

Hi all,
We've just finished with success a wicket project for a large online retailer. 
I think wicket is the best framework out there, but as any other project there 
is room for improvement. I will talk about some topics bellow, I hope it can 
help in some way.

- Separation of corcerns
I think we could get a better separation of concerns if page class were focused 
more in behavior and html were more focused in display (or view).
What I mean is, some times we have components that the main purpose is to add 
behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping. 
Take CheckGroup for exaple, it is a component focused on behavior, even though 
we have to add a reference to it in HTML.

When creating composite input fields (like date), the usual way is to create a 
panel even if you are not interested in reusability. A interesting aproach is 
to insert a hidden text field in HTML mapped to a component that controls other 
components input. It makes easier to integrate with designer and to preview in 
browser. If we didn't have this limitation the hidden input would not be 
necessary and the development of behavior focused components would be easier.

One thing that bothers me is when our designer move things around in HTML and 
we get "added a component in code but forgot to reference it in the markup" 
error, because of component hierarchy. Html tags position is a view problem not 
a behavior problem, so why bother in java?

Another issue, is when we want to change the class of a div, for example, and 
have to change our whole page hierarchy in java, just to manipulate that tag.

So I think a hierarchy more focused on components behavior (for example taking 
care of inherited models and inputs), rather than tags position in HTML would 
be better. This would make wicket more flexible and easier to work with.

- Too many finals modifiers
It's hard for a API or framework designer to foresee all uses and unxepected 
situations its users may face in day to day development. Final modifiers places 
a additional challenge when facing these situations. In project were deadlines 
are in place, there is little room for submiting a request and waiting for a 
new version to be released. Furthermore, unfortunately, it's not possible to 
mock final methods making it harder sometimes to test wicket related 
classes/components. What we had to do internally, is to have our own version of 
wicket, mainly to remove final modifiers when necessary, a clear violation of 
open/closed principle.

- Ajax
Wicket offers no stateless ajax and often changes HTML id, which makes harder 
to integrate with a 3rd party ajax framework. Is there any hope for constructor 
change?

Please let me know your thoughts, keep up the good work.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


  The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. 
http://in.yahoo.com/

Re: Wicket feedback

[sudhir543-dev]

 +1 for last point "Too many finals modifiers" 
and subclassing isnt always better than listeners - My 2cents 



  

Sudhir NimavatSenior software engineer. 
Quick start global PVT LTD.
Baroda - 390007
Gujarat, India

Personally I'm always ready to learn, although I do not always like being taught
  





From: Ricardo Mayerhofer 
To: users@wicket.apache.org
Sent: Tue, 22 December, 2009 6:49:02 PM
Subject: Wicket feedback

Hi all,
We've just finished with success a wicket project for a large online retailer. 
I think wicket is the best framework out there, but as any other project there 
is room for improvement. I will talk about some topics bellow, I hope it can 
help in some way.

- Separation of corcerns
I think we could get a better separation of concerns if page class were focused 
more in behavior and html were more focused in display (or view).
What I mean is, some times we have components that the main purpose is to add 
behavior, and we have to add extra markup just to satisfy wicket 1:1 mapping. 
Take CheckGroup for exaple, it is a component focused on behavior, even though 
we have to add a reference to it in HTML.

When creating composite input fields (like date), the usual way is to create a 
panel even if you are not interested in reusability. A interesting aproach is 
to insert a hidden text field in HTML mapped to a component that controls other 
components input. It makes easier to integrate with designer and to preview in 
browser. If we didn't have this limitation the hidden input would not be 
necessary and the development of behavior focused components would be easier.

One thing that bothers me is when our designer move things around in HTML and 
we get "added a component in code but forgot to reference it in the markup" 
error, because of component hierarchy. Html tags position is a view problem not 
a behavior problem, so why bother in java?

Another issue, is when we want to change the class of a div, for example, and 
have to change our whole page hierarchy in java, just to manipulate that tag.

So I think a hierarchy more focused on components behavior (for example taking 
care of inherited models and inputs), rather than tags position in HTML would 
be better. This would make wicket more flexible and easier to work with.

- Too many finals modifiers
It's hard for a API or framework designer to foresee all uses and unxepected 
situations its users may face in day to day development. Final modifiers places 
a additional challenge when facing these situations. In project were deadlines 
are in place, there is little room for submiting a request and waiting for a 
new version to be released. Furthermore, unfortunately, it's not possible to 
mock final methods making it harder sometimes to test wicket related 
classes/components. What we had to do internally, is to have our own version of 
wicket, mainly to remove final modifiers when necessary, a clear violation of 
open/closed principle.

- Ajax
Wicket offers no stateless ajax and often changes HTML id, which makes harder 
to integrate with a 3rd party ajax framework. Is there any hope for constructor 
change?

Please let me know your thoughts, keep up the good work.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


  The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. 
http://in.yahoo.com/

Re: Adding components to page (dynamically)

[bgooren]

Well, you need to have some html in the container with wicket:id="win1" for
your code to work. Wicket is (correctly) complaining that it cannot locate
html for your component. What kind of component is Window? (it's not a
standard wicket component)


marioosh.net wrote:
> 
> 
> 
> marioosh.net wrote:
>> 
>> I have a Window component (Panel subclass) and button to dynamic
>> adding new Window to Base page,
>> but when i click this button (AjaxLink) i get error:
>> 
>> WicketMessage: Unable to find the markup for the component. That may
>> be due to transparent containers or components implementing
>> IComponentResolver: [MarkupContainer [Component id = win1]]
>> 
>> Base.html:
>> 
>>   # new 
>> 
>> 
>> Base.java:
>> public class Base extends WebPage {
>>  public Base() {
>>  
>>  add(new AjaxLink("new"){
>>  @Override
>>  public void onClick(AjaxRequestTarget target) {
>>  Window win = new Window("win1","title");
>>  win.setOutputMarkupId(true);
>>  add(win);
>>  target.addComponent(win); // ajax refresh
>>  }
>>  });
>>  }
>> }
>> 
>> -- 
>> Greetings,
>> marioosh
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>> 
>> 
>> 
> 
> 
> I changed my code, but now i get error:
> WicketMessage: The component(s) below failed to render. A common problem
> is that you have added a component in code but forgot to reference it in
> the markup (thus the component will never be rendered).
> 
> 1. [MarkupContainer [Component id = win1]]
> ...
> 
> Base.java:
> public class Base extends WebPage {
>   public Base() {
> 
>   final WebMarkupContainer m = new 
> WebMarkupContainer("container");   
>   m.setOutputMarkupId(true);
>   add(m);
>   add(new AjaxLink("new"){
>   @Override
>   public void onClick(AjaxRequestTarget target) {
>   Window win = new Window("win1","...");
>   m.add(win);
>   target.addComponent(m);
>   }
>   });
>   }
> }
> 
> Base.html:
> 
># new 
>  
> 
> 
> Anybody help with that ?
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Adding-components-to-page-%28dynamically%29-tp26886670p26888242.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Wicket feedback

[Ricardo Mayerhofer]

Hi all,
We've just finished with success a wicket project for a large online 
retailer. I think wicket is the best framework out there, but as any 
other project there is room for improvement. I will talk about some 
topics bellow, I hope it can help in some way.


- Separation of corcerns
I think we could get a better separation of concerns if page class were 
focused more in behavior and html were more focused in display (or view).
What I mean is, some times we have components that the main purpose is 
to add behavior, and we have to add extra markup just to satisfy wicket 
1:1 mapping. Take CheckGroup for exaple, it is a component focused on 
behavior, even though we have to add a reference to it in HTML.


When creating composite input fields (like date), the usual way is to 
create a panel even if you are not interested in reusability. A 
interesting aproach is to insert a hidden text field in HTML mapped to a 
component that controls other components input. It makes easier to 
integrate with designer and to preview in browser. If we didn't have 
this limitation the hidden input would not be necessary and the 
development of behavior focused components would be easier.


One thing that bothers me is when our designer move things around in 
HTML and we get "added a component in code but forgot to reference it in 
the markup" error, because of component hierarchy. Html tags position is 
a view problem not a behavior problem, so why bother in java?


Another issue, is when we want to change the class of a div, for 
example, and have to change our whole page hierarchy in java, just to 
manipulate that tag.


So I think a hierarchy more focused on components behavior (for example 
taking care of inherited models and inputs), rather than tags position 
in HTML would be better. This would make wicket more flexible and easier 
to work with.


- Too many finals modifiers
It's hard for a API or framework designer to foresee all uses and 
unxepected situations its users may face in day to day development. 
Final modifiers places a additional challenge when facing these 
situations. In project were deadlines are in place, there is little room 
for submiting a request and waiting for a new version to be released. 
Furthermore, unfortunately, it's not possible to mock final methods 
making it harder sometimes to test wicket related classes/components. 
What we had to do internally, is to have our own version of wicket, 
mainly to remove final modifiers when necessary, a clear violation of 
open/closed principle.


- Ajax
Wicket offers no stateless ajax and often changes HTML id, which makes 
harder to integrate with a 3rd party ajax framework. Is there any hope 
for constructor change?


Please let me know your thoughts, keep up the good work.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: resize and crop web images

[nino martinez wael]

sure theres a lot, if you want do to fancy image manipulation and
detection you could use imagemagic. Otherwise just google "java crop"

2009/12/22 Christoph Grün :
> Hi,
>
> Is there a project/work that allows to resize and crop web images?
> I would like to show Wikipedia images in a list, each displayed as e.g.,
> 100*100 px .
>
> Thanks a lot,
> Chris
>
>
> -
> 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: Tag Oriented Development

[Martin Makundi]

JSF is just open source. Wicket is open source too.

> Second link was  of a joke , wasn't it?

IBM is giving courses in Wicket, so it must be true:
http://www.ibm.com/developerworks/edu/os-dw-os-ag-wicket.html

I just whish IBM had a bigger brand name.. only three letters.

**
Martin

2009/12/22 Ernesto Reinaldo Barreiro :
>
>
> Best,
>
> Ernesto
>
> On Tue, Dec 22, 2009 at 1:37 PM, Martin Makundi <
> martin.maku...@koodaripalvelut.com> wrote:
>
>> > But the problem is those who will take the final decision will take
>> > into account more "political" reasons ...
>>
>> Political?! You mean boneless ok, nobody ever got fired for
>> choosing IBM. But IBM is on board too:
>>
>> - http://www.ibm.com/developerworks/web/library/wa-aj-wicket/index.html
>> -
>> http://old.nabble.com/IBM-to-adopt-Wicket-as-standard-web-framework-to9674233.html
>>
>> **
>> Martin
>>
>> -
>> 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: Tag Oriented Development

[Ernesto Reinaldo Barreiro]

Named boneless if you want;-) The fact is that things like "support" and
"big names"

Second link was  of a joke , wasn't it?

Best,

Ernesto

On Tue, Dec 22, 2009 at 1:37 PM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:

> > But the problem is those who will take the final decision will take
> > into account more "political" reasons ...
>
> Political?! You mean boneless ok, nobody ever got fired for
> choosing IBM. But IBM is on board too:
>
> - http://www.ibm.com/developerworks/web/library/wa-aj-wicket/index.html
> -
> http://old.nabble.com/IBM-to-adopt-Wicket-as-standard-web-framework-to9674233.html
>
> **
> Martin
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

resize and crop web images

[Christoph Grün]

Hi,

Is there a project/work that allows to resize and crop web images?
I would like to show Wikipedia images in a list, each displayed as e.g.,
100*100 px . 

Thanks a lot,
Chris


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Tag Oriented Development

[Martijn Dashorst]

The best april fools jokes are those that still fool fools, even 4
years after...


Martijn

On Tue, Dec 22, 2009 at 1:37 PM, Martin Makundi
 wrote:
>> But the problem is those who will take the final decision will take
>> into account more "political" reasons ...
>
> Political?! You mean boneless ok, nobody ever got fired for
> choosing IBM. But IBM is on board too:
>
> - http://www.ibm.com/developerworks/web/library/wa-aj-wicket/index.html
> - 
> http://old.nabble.com/IBM-to-adopt-Wicket-as-standard-web-framework-to9674233.html
>
> **
> Martin
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Tag Oriented Development

[Altuğ B . Altıntaş]

In business, decision makers choose standards and JSF is standard so JSF is
good and JSF is the King. But couldn't be "The King Is Naked" ??

OR

Am i wrong ? JSF is really cool and i don't know the hidden features ??

I don't want to start framework wars, this is useless but I think Wicket
should be a JSR.

I don't know how a framework like Wicket become a JSR - a standard - but it
should be...


2009/12/22 Peter Thomas 

> On Tue, Dec 22, 2009 at 5:47 PM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > @Tomas, @Martin,
> >
> > I already knew those links... Thanks anyway. Actually I went a bit
> further
> > an implemented the same "application" on different technologies so that
> > developers could evaluate for themselves the wonders of "downsides" of
> each
> > technology... plus detailed explanations of how the code works
> > Unfortunately I cannot share that code as is property of the company I
> work
> > for
>
>
> That's a pretty solid approach, pity you can't share the code though.  I
> tried to do something similar as open-source:
> http://code.google.com/p/perfbench/
>
> Maybe you can contribute some analysis or even an implementation or two ;)
> I would be interested in your feedback, for e.g. which framework to attempt
> next - do let me know offline.
>
>
>
> > But the problem is those who will take the final decision will take
> > into account more "political" reasons that things like "development
> speed",
> > "code quality", "code re-usability" and any other adds you throw at
> them...
> >
> >
> > @Martin,
> >
> > Congratulations!  Hope I can say the same in  a few months.
> >
> > Best,
> >
> > Ernesto
> >
> > On Tue, Dec 22, 2009 at 12:57 PM, Peter Thomas 
> > wrote:
> >
> > > On Tue, Dec 22, 2009 at 5:22 PM, Ernesto Reinaldo Barreiro <
> > > reier...@gmail.com> wrote:
> > >
> > > > Hi Eelco,
> > > >
> > > > On Tue, Dec 22, 2009 at 12:38 PM, Eelco Hillenius <
> > > > eelco.hillen...@gmail.com
> > > > > wrote:
> > > >
> > > > > > I love Wicket and the natural approach it offers to do
> > > > web-development...
> > > > > > and I have been pushing hard to use it whenever possible...  but
> on
> > > the
> > > > > > "real world" it is not enough to be an excellent product to gain
> > > > > > wide acceptance...  Does last sentence ring a bell?
> > > > >
> > > > > I think we've gained pretty wide acceptance actually. Wicket In
> > Action
> > > > > has been a best seller for Manning in the months right after it
> came
> > > > > out, and Wicket is by many considered as one of the leading web
> > > > > frameworks for Java. We've also had one of the most active email
> > lists
> > > > > for years now. I'm sure Wicket lags behind JSF and Struts
> > considerably
> > > > > when it comes to number of users, but hey, why would we care. You
> > only
> > > > > need a bunch of serious users to maintain a framework, and Wicket
> has
> > > > > many thousands of them :-)
> > > > >
> > > > > You don't have to convince me about Wicket excellence! I love
> Wicket,
> > > > I've
> > > > been using it for over two years now, and right now I'm doing all my
> > > > efforts
> > > > to get it adopted at the company I'm working for... But being
> realistic
> > > > they
> > > > will probably jump to Struts 2, or Seam-JSF...
> > > >
> > > > After re-reading my message  I see maybe it was bit "pessimistic"..
> > maybe
> > > > out of my present frustration.
> > > >
> > >
> > > may be useful when debating Wicket vs JSF where you work etc:
> > > http://tinyurl.com/jsf-sucks
> > >
> > > - Peter
> > >
> > >
> > > >
> > > > Cheers,
> > > >
> > > > Ernesto
> > > >
> > >
> >
>



-- 
Altuğ.

Re: Tag Oriented Development

[Martin Makundi]

> But the problem is those who will take the final decision will take
> into account more "political" reasons ...

Political?! You mean boneless ok, nobody ever got fired for
choosing IBM. But IBM is on board too:

- http://www.ibm.com/developerworks/web/library/wa-aj-wicket/index.html
- 
http://old.nabble.com/IBM-to-adopt-Wicket-as-standard-web-framework-to9674233.html

**
Martin

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Tag Oriented Development

[Peter Thomas]

On Tue, Dec 22, 2009 at 5:47 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> @Tomas, @Martin,
>
> I already knew those links... Thanks anyway. Actually I went a bit further
> an implemented the same "application" on different technologies so that
> developers could evaluate for themselves the wonders of "downsides" of each
> technology... plus detailed explanations of how the code works
> Unfortunately I cannot share that code as is property of the company I work
> for


That's a pretty solid approach, pity you can't share the code though.  I
tried to do something similar as open-source:
http://code.google.com/p/perfbench/

Maybe you can contribute some analysis or even an implementation or two ;)
I would be interested in your feedback, for e.g. which framework to attempt
next - do let me know offline.



> But the problem is those who will take the final decision will take
> into account more "political" reasons that things like "development speed",
> "code quality", "code re-usability" and any other adds you throw at them...
>
>
> @Martin,
>
> Congratulations!  Hope I can say the same in  a few months.
>
> Best,
>
> Ernesto
>
> On Tue, Dec 22, 2009 at 12:57 PM, Peter Thomas 
> wrote:
>
> > On Tue, Dec 22, 2009 at 5:22 PM, Ernesto Reinaldo Barreiro <
> > reier...@gmail.com> wrote:
> >
> > > Hi Eelco,
> > >
> > > On Tue, Dec 22, 2009 at 12:38 PM, Eelco Hillenius <
> > > eelco.hillen...@gmail.com
> > > > wrote:
> > >
> > > > > I love Wicket and the natural approach it offers to do
> > > web-development...
> > > > > and I have been pushing hard to use it whenever possible...  but on
> > the
> > > > > "real world" it is not enough to be an excellent product to gain
> > > > > wide acceptance...  Does last sentence ring a bell?
> > > >
> > > > I think we've gained pretty wide acceptance actually. Wicket In
> Action
> > > > has been a best seller for Manning in the months right after it came
> > > > out, and Wicket is by many considered as one of the leading web
> > > > frameworks for Java. We've also had one of the most active email
> lists
> > > > for years now. I'm sure Wicket lags behind JSF and Struts
> considerably
> > > > when it comes to number of users, but hey, why would we care. You
> only
> > > > need a bunch of serious users to maintain a framework, and Wicket has
> > > > many thousands of them :-)
> > > >
> > > > You don't have to convince me about Wicket excellence! I love Wicket,
> > > I've
> > > been using it for over two years now, and right now I'm doing all my
> > > efforts
> > > to get it adopted at the company I'm working for... But being realistic
> > > they
> > > will probably jump to Struts 2, or Seam-JSF...
> > >
> > > After re-reading my message  I see maybe it was bit "pessimistic"..
> maybe
> > > out of my present frustration.
> > >
> >
> > may be useful when debating Wicket vs JSF where you work etc:
> > http://tinyurl.com/jsf-sucks
> >
> > - Peter
> >
> >
> > >
> > > Cheers,
> > >
> > > Ernesto
> > >
> >
>

Re: Tag Oriented Development

[Ernesto Reinaldo Barreiro]

@Tomas, @Martin,

I already knew those links... Thanks anyway. Actually I went a bit further
an implemented the same "application" on different technologies so that
developers could evaluate for themselves the wonders of "downsides" of each
technology... plus detailed explanations of how the code works
Unfortunately I cannot share that code as is property of the company I work
for But the problem is those who will take the final decision will take
into account more "political" reasons that things like "development speed",
"code quality", "code re-usability" and any other adds you throw at them...


@Martin,

Congratulations!  Hope I can say the same in  a few months.

Best,

Ernesto

On Tue, Dec 22, 2009 at 12:57 PM, Peter Thomas  wrote:

> On Tue, Dec 22, 2009 at 5:22 PM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > Hi Eelco,
> >
> > On Tue, Dec 22, 2009 at 12:38 PM, Eelco Hillenius <
> > eelco.hillen...@gmail.com
> > > wrote:
> >
> > > > I love Wicket and the natural approach it offers to do
> > web-development...
> > > > and I have been pushing hard to use it whenever possible...  but on
> the
> > > > "real world" it is not enough to be an excellent product to gain
> > > > wide acceptance...  Does last sentence ring a bell?
> > >
> > > I think we've gained pretty wide acceptance actually. Wicket In Action
> > > has been a best seller for Manning in the months right after it came
> > > out, and Wicket is by many considered as one of the leading web
> > > frameworks for Java. We've also had one of the most active email lists
> > > for years now. I'm sure Wicket lags behind JSF and Struts considerably
> > > when it comes to number of users, but hey, why would we care. You only
> > > need a bunch of serious users to maintain a framework, and Wicket has
> > > many thousands of them :-)
> > >
> > > You don't have to convince me about Wicket excellence! I love Wicket,
> > I've
> > been using it for over two years now, and right now I'm doing all my
> > efforts
> > to get it adopted at the company I'm working for... But being realistic
> > they
> > will probably jump to Struts 2, or Seam-JSF...
> >
> > After re-reading my message  I see maybe it was bit "pessimistic".. maybe
> > out of my present frustration.
> >
>
> may be useful when debating Wicket vs JSF where you work etc:
> http://tinyurl.com/jsf-sucks
>
> - Peter
>
>
> >
> > Cheers,
> >
> > Ernesto
> >
>

Re: Tag Oriented Development

[Pieter Degraeuwe]

"Once it reaches
that point there is no turning back because to change would be to admit
they weren't perfect at some point in the past"

I wouldn't say that. If you have a look to the EJB1 en EJB2 api/spec, they
differ 90% from EJB3. At least with EJB they really saw that the initial
design was not sufficient... Hopefully the guys of JSF have the guts to do
the same...

On Tue, Dec 22, 2009 at 10:59 AM, Chris Colman  wrote:

> > > > I know JSF is standard; what is your idea about current JSF
> status?
> > >
> > > Just forget about it ... ;)
>
> Agreed!
>
> > JSF is way too complex for doing simple things. They -again- forgot
> the
> > KISS principle (Keep it Simple & Straightforward/Stupid).
> >
> > Wicket (but also Tapestry) is in my opinion a giant leap forward. I
> > wondaer when the JSF spec will start look like this way of working...
>
> Probably never because often what starts out as an unjustifiable and
> unattractive design that is adopted by people simply because it doesn't
> stray too far from the legacy "framework" (JSP) soon becomes "justified"
> on the basis of some irrational, semi religious beliefs. Once it reaches
> that point there is no turning back because to change would be to admit
> they weren't perfect at some point in the past.
>
> The good thing is that rational people are free to choose the best
> solution regardless of what 'the standard' might be.
>
> It's a good thing that many programmers are usually freedom fighting
> mavericks or we'd all be writing desktop apps in Visual Basic (not that
> I ever used VB - I was more a C/C++ kind of guy =] )
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Pieter Degraeuwe
Systemworks bvba
Belgiëlaan 61
9070 Destelbergen
GSM: +32 (0)485/68.60.85
Email: pieter.degrae...@systemworks.be
visit us at http://www.systemworks.be

Re: Tag Oriented Development

[Martin Makundi]

I just love advocating wicket into large corporations... :)

"What are you going to do about the open bugs?" "And they say that
wicket's generics implementation is highly experimental, that doesn't
sound very trustworthy, does it?"

But eventually we succeed.

Articles like the following are very useful when negotiating:
* 
http://www.indicthreads.com/news/435/wicket_java_framework_saves_programming_time.html
* 
http://ptrthomas.wordpress.com/2009/01/14/seam-jsf-vs-wicket-performance-comparison/
* http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/

**
Martin

2009/12/22 Ernesto Reinaldo Barreiro :
> Hi Eelco,
>
> On Tue, Dec 22, 2009 at 12:38 PM, Eelco Hillenius > wrote:
>
>> > I love Wicket and the natural approach it offers to do web-development...
>> > and I have been pushing hard to use it whenever possible...  but on the
>> > "real world" it is not enough to be an excellent product to gain
>> > wide acceptance...  Does last sentence ring a bell?
>>
>> I think we've gained pretty wide acceptance actually. Wicket In Action
>> has been a best seller for Manning in the months right after it came
>> out, and Wicket is by many considered as one of the leading web
>> frameworks for Java. We've also had one of the most active email lists
>> for years now. I'm sure Wicket lags behind JSF and Struts considerably
>> when it comes to number of users, but hey, why would we care. You only
>> need a bunch of serious users to maintain a framework, and Wicket has
>> many thousands of them :-)
>>
>> You don't have to convince me about Wicket excellence! I love Wicket, I've
> been using it for over two years now, and right now I'm doing all my efforts
> to get it adopted at the company I'm working for... But being realistic they
> will probably jump to Struts 2, or Seam-JSF...
>
> After re-reading my message  I see maybe it was bit "pessimistic".. maybe
> out of my present frustration.
>
> Cheers,
>
> Ernesto
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Tag Oriented Development

[Peter Thomas]

On Tue, Dec 22, 2009 at 5:22 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi Eelco,
>
> On Tue, Dec 22, 2009 at 12:38 PM, Eelco Hillenius <
> eelco.hillen...@gmail.com
> > wrote:
>
> > > I love Wicket and the natural approach it offers to do
> web-development...
> > > and I have been pushing hard to use it whenever possible...  but on the
> > > "real world" it is not enough to be an excellent product to gain
> > > wide acceptance...  Does last sentence ring a bell?
> >
> > I think we've gained pretty wide acceptance actually. Wicket In Action
> > has been a best seller for Manning in the months right after it came
> > out, and Wicket is by many considered as one of the leading web
> > frameworks for Java. We've also had one of the most active email lists
> > for years now. I'm sure Wicket lags behind JSF and Struts considerably
> > when it comes to number of users, but hey, why would we care. You only
> > need a bunch of serious users to maintain a framework, and Wicket has
> > many thousands of them :-)
> >
> > You don't have to convince me about Wicket excellence! I love Wicket,
> I've
> been using it for over two years now, and right now I'm doing all my
> efforts
> to get it adopted at the company I'm working for... But being realistic
> they
> will probably jump to Struts 2, or Seam-JSF...
>
> After re-reading my message  I see maybe it was bit "pessimistic".. maybe
> out of my present frustration.
>

may be useful when debating Wicket vs JSF where you work etc:
http://tinyurl.com/jsf-sucks

- Peter


>
> Cheers,
>
> Ernesto
>

Re: Tag Oriented Development

[Altuğ B . Altıntaş]

I agree with you.

I think becoming a JSR also adds lots of friction to development.


2009/12/22 nino martinez wael 

> Could'nt one petition a JSR for wicket? :)
>
> -regards Nino
>
> 2009/12/22 Chris Colman :
> >> > > I know JSF is standard; what is your idea about current JSF
> > status?
> >> >
> >> > Just forget about it ... ;)
> >
> > Agreed!
> >
> >> JSF is way too complex for doing simple things. They -again- forgot
> > the
> >> KISS principle (Keep it Simple & Straightforward/Stupid).
> >>
> >> Wicket (but also Tapestry) is in my opinion a giant leap forward. I
> >> wondaer when the JSF spec will start look like this way of working...
> >
> > Probably never because often what starts out as an unjustifiable and
> > unattractive design that is adopted by people simply because it doesn't
> > stray too far from the legacy "framework" (JSP) soon becomes "justified"
> > on the basis of some irrational, semi religious beliefs. Once it reaches
> > that point there is no turning back because to change would be to admit
> > they weren't perfect at some point in the past.
> >
> > The good thing is that rational people are free to choose the best
> > solution regardless of what 'the standard' might be.
> >
> > It's a good thing that many programmers are usually freedom fighting
> > mavericks or we'd all be writing desktop apps in Visual Basic (not that
> > I ever used VB - I was more a C/C++ kind of guy =] )
> >
> >
> > -
> > 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
>
>


-- 
Altuğ.

Re: Tag Oriented Development

[Ernesto Reinaldo Barreiro]

Hi Eelco,

On Tue, Dec 22, 2009 at 12:38 PM, Eelco Hillenius  wrote:

> > I love Wicket and the natural approach it offers to do web-development...
> > and I have been pushing hard to use it whenever possible...  but on the
> > "real world" it is not enough to be an excellent product to gain
> > wide acceptance...  Does last sentence ring a bell?
>
> I think we've gained pretty wide acceptance actually. Wicket In Action
> has been a best seller for Manning in the months right after it came
> out, and Wicket is by many considered as one of the leading web
> frameworks for Java. We've also had one of the most active email lists
> for years now. I'm sure Wicket lags behind JSF and Struts considerably
> when it comes to number of users, but hey, why would we care. You only
> need a bunch of serious users to maintain a framework, and Wicket has
> many thousands of them :-)
>
> You don't have to convince me about Wicket excellence! I love Wicket, I've
been using it for over two years now, and right now I'm doing all my efforts
to get it adopted at the company I'm working for... But being realistic they
will probably jump to Struts 2, or Seam-JSF...

After re-reading my message  I see maybe it was bit "pessimistic".. maybe
out of my present frustration.

Cheers,

Ernesto

Re: Tag Oriented Development

[Eelco Hillenius]

> I love Wicket and the natural approach it offers to do web-development...
> and I have been pushing hard to use it whenever possible...  but on the
> "real world" it is not enough to be an excellent product to gain
> wide acceptance...  Does last sentence ring a bell?

I think we've gained pretty wide acceptance actually. Wicket In Action
has been a best seller for Manning in the months right after it came
out, and Wicket is by many considered as one of the leading web
frameworks for Java. We've also had one of the most active email lists
for years now. I'm sure Wicket lags behind JSF and Struts considerably
when it comes to number of users, but hey, why would we care. You only
need a bunch of serious users to maintain a framework, and Wicket has
many thousands of them :-)

Eelco

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Adding components to page (dynamically)

[marioosh.net]

marioosh.net wrote:
> 
> I have a Window component (Panel subclass) and button to dynamic
> adding new Window to Base page,
> but when i click this button (AjaxLink) i get error:
> 
> WicketMessage: Unable to find the markup for the component. That may
> be due to transparent containers or components implementing
> IComponentResolver: [MarkupContainer [Component id = win1]]
> 
> Base.html:
> 
># new 
> 
> 
> Base.java:
> public class Base extends WebPage {
>   public Base() {
>   
>   add(new AjaxLink("new"){
>   @Override
>   public void onClick(AjaxRequestTarget target) {
>   Window win = new Window("win1","title");
>   win.setOutputMarkupId(true);
>   add(win);
>   target.addComponent(win); // ajax refresh
>   }
>   });
>   }
> }
> 
> -- 
> Greetings,
> marioosh
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 


I changed my code, but now i get error:
WicketMessage: The component(s) below failed to render. A common problem is
that you have added a component in code but forgot to reference it in the
markup (thus the component will never be rendered).

1. [MarkupContainer [Component id = win1]]
...

Base.java:
public class Base extends WebPage {
public Base() {

final WebMarkupContainer m = new 
WebMarkupContainer("container");   
m.setOutputMarkupId(true);
add(m);
add(new AjaxLink("new"){
@Override
public void onClick(AjaxRequestTarget target) {
Window win = new Window("win1","...");
m.add(win);
target.addComponent(m);
}
});
}
}

Base.html:

 # new 
   


Anybody help with that ?

-- 
View this message in context: 
http://old.nabble.com/Adding-components-to-page-%28dynamically%29-tp26886670p26886911.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Tag Oriented Development

[Ernesto Reinaldo Barreiro]

IMHO the keys fo JSF "success" are:

-They sell it as a standard with companies backing it up. It doesn't matter
if it is an over complicated model and that you need things like JBoss Seam
to fix it. On many companies decisions are taken by pointy haired bosses...
and they like to hear to the words "standard" and "official support". So, if
things go wild they have "support"... and some one else to blame.
-It is more easy to find developers knowing (willing to learn) JSF... At
least on Spain  it is rather difficult to find Job opportunities as a
Wicket developer or as a Tapestry or as that-ever-else != (struts or
JSF)-developer.

I love Wicket and the natural approach it offers to do web-development...
and I have been pushing hard to use it whenever possible...  but on the
"real world" it is not enough to be an excellent product to gain
wide acceptance...  Does last sentence ring a bell?

Best,

Ernesto



On Tue, Dec 22, 2009 at 10:59 AM, Chris Colman  wrote:

> > > > I know JSF is standard; what is your idea about current JSF
> status?
> > >
> > > Just forget about it ... ;)
>
> Agreed!
>
> > JSF is way too complex for doing simple things. They -again- forgot
> the
> > KISS principle (Keep it Simple & Straightforward/Stupid).
> >
> > Wicket (but also Tapestry) is in my opinion a giant leap forward. I
> > wondaer when the JSF spec will start look like this way of working...
>
> Probably never because often what starts out as an unjustifiable and
> unattractive design that is adopted by people simply because it doesn't
> stray too far from the legacy "framework" (JSP) soon becomes "justified"
> on the basis of some irrational, semi religious beliefs. Once it reaches
> that point there is no turning back because to change would be to admit
> they weren't perfect at some point in the past.
>
> The good thing is that rational people are free to choose the best
> solution regardless of what 'the standard' might be.
>
> It's a good thing that many programmers are usually freedom fighting
> mavericks or we'd all be writing desktop apps in Visual Basic (not that
> I ever used VB - I was more a C/C++ kind of guy =] )
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Adding components to page (dynamically)

[marioosh.net]

I have a Window component (Panel subclass) and button to dynamic
adding new Window to Base page,
but when i click this button (AjaxLink) i get error:

WicketMessage: Unable to find the markup for the component. That may
be due to transparent containers or components implementing
IComponentResolver: [MarkupContainer [Component id = win1]]

Base.html:

new


Base.java:
public class Base extends WebPage {
public Base() {

add(new AjaxLink("new"){
@Override
public void onClick(AjaxRequestTarget target) {
Window win = new Window("win1","title");
win.setOutputMarkupId(true);
add(win);
target.addComponent(win); // ajax refresh
}
});
}
}

-- 
Greetings,
marioosh

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Tag Oriented Development

[nino martinez wael]

Could'nt one petition a JSR for wicket? :)

-regards Nino

2009/12/22 Chris Colman :
>> > > I know JSF is standard; what is your idea about current JSF
> status?
>> >
>> > Just forget about it ... ;)
>
> Agreed!
>
>> JSF is way too complex for doing simple things. They -again- forgot
> the
>> KISS principle (Keep it Simple & Straightforward/Stupid).
>>
>> Wicket (but also Tapestry) is in my opinion a giant leap forward. I
>> wondaer when the JSF spec will start look like this way of working...
>
> Probably never because often what starts out as an unjustifiable and
> unattractive design that is adopted by people simply because it doesn't
> stray too far from the legacy "framework" (JSP) soon becomes "justified"
> on the basis of some irrational, semi religious beliefs. Once it reaches
> that point there is no turning back because to change would be to admit
> they weren't perfect at some point in the past.
>
> The good thing is that rational people are free to choose the best
> solution regardless of what 'the standard' might be.
>
> It's a good thing that many programmers are usually freedom fighting
> mavericks or we'd all be writing desktop apps in Visual Basic (not that
> I ever used VB - I was more a C/C++ kind of guy =] )
>
>
> -
> 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: Tag Oriented Development

[Chris Colman]

> > > I know JSF is standard; what is your idea about current JSF
status?
> >
> > Just forget about it ... ;)

Agreed!

> JSF is way too complex for doing simple things. They -again- forgot
the
> KISS principle (Keep it Simple & Straightforward/Stupid).
> 
> Wicket (but also Tapestry) is in my opinion a giant leap forward. I
> wondaer when the JSF spec will start look like this way of working...

Probably never because often what starts out as an unjustifiable and
unattractive design that is adopted by people simply because it doesn't
stray too far from the legacy "framework" (JSP) soon becomes "justified"
on the basis of some irrational, semi religious beliefs. Once it reaches
that point there is no turning back because to change would be to admit
they weren't perfect at some point in the past.

The good thing is that rational people are free to choose the best
solution regardless of what 'the standard' might be.

It's a good thing that many programmers are usually freedom fighting
mavericks or we'd all be writing desktop apps in Visual Basic (not that
I ever used VB - I was more a C/C++ kind of guy =] )


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Tag Oriented Development

[Pieter Degraeuwe]

In my opinion, this is exactly the mistake of JSF. (and struts/jsp, etc).
They keep putting logic (in the form of tags) in the markup.
How long will it take until people understand that markup/xml is NOT a
programming language?
You have to seperate logic and markup. You cannot mix them.

Also JSF is not enough OO. OO should encourage componenr reuse. JSF
component structure is too complex to make reusable components. (It is
possible however, but it must be easy. MUCH easier that it is now today.
The same mistake was made with the EJB spec 1 and 2. Version 3 did fix this
(more or less).
JSF is way too complex for doing simple things. They -again- forgot the KISS
principle (Keep it Simple & Straightforward/Stupid).

Wicket (but also Tapestry) is in my opinion a giant leap forward. I wondaer
when the JSF spec will start look like this way of working...

My 2 cents...

Pieter

On Mon, Dec 21, 2009 at 1:53 PM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:

> > I know JSF is standard; what is your idea about current JSF status?
>
> Just forget about it ... ;)
>
> **
> Martin
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Pieter Degraeuwe
Systemworks bvba
Belgiëlaan 61
9070 Destelbergen
GSM: +32 (0)485/68.60.85
Email: pieter.degrae...@systemworks.be
visit us at http://www.systemworks.be