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 <igor.vaynb...@gmail.com>
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, <sudhir543-...@yahoo.com> 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 <igor.vaynb...@gmail.com>
> 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, <sudhir543-...@yahoo.com> 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 <ricardo.ekm.lis...@gmail.com>
>> 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
>
>
> 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
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.
http://in.yahoo.com/
