>>The problem is that with declarative approaches,
once you step outside of the use-cases envisioned by
the designer of the declarative system things become
much more difficult.

I would like to think practical. How many such
unexpected situations would happen? Besides, you can
always code extra validation in Java in controllers
using things such as Wicket's form validators.



>>A Wicketer would view it differently: in
Valang+Spring MVC you have Java code for your
controller and validation "code" in XML, whereas in 
Wicket it's all in Java code. That said, it probably
wouldn't be too hard to implement a FormValidator
that accepted valang syntax and applied it to a form.

I really want to see such a thing in place.
Auto-generation of client-side validation code, IMHO,
is a much needed thing. At least, Wicket should have
this capability. It would be nightmare to wrtie
validation twice: one for the WebPage, one for
client-side validation.



>>Weird. Your experience is exactly opposite to mine.
I found Spring MVC to be hopelessly scattered:
declarations in XML, controller code in Java, view
code in templates.

I dont have any real experience yet. It is mere my
observation and thinking. I am learning but still
evaluating. 

One thing I have is really the opposite to your
experience. I feel this "scatter" is not hopeless; but
it is a nice separation of concerns. Think about it. I
have no objection to puting everything in WebPage, but
these different concerns should be separated in Wicket
somehow, code should look clean and good...

Thank you for sharing your thought and experience,
which is immensely helpful!

Regards.






============ previous emails =============



--- John Krasnay <[EMAIL PROTECTED]> wrote:

> On Fri, May 02, 2008 at 07:25:01AM -0700, David
> Chang wrote:
> > 
> > I have the bad feeling about this way of
> validation
> > 
> > 1. It is too much coding. Anybody used Valang in
> > Spring Module? By using Valang, the validation
> code is
> > much clean and a lot fewer and you dont need to
> create
> > a class simply for this simple validation.
> > 
> 
> I think you'll find the Wicket team has very strong
> aversion to doing
> things declaratively rather than with Java code. The
> problem is that
> with declarative approaches, once you step outside
> of the use-cases
> envisioned by the designer of the declarative system
> things become much
> more difficult.
> 
> > 2. Valang covers both client AND server-side
> > validation. Please note that client-side
> validation is
> > equally important as server-side's. I feel it is a
> > must for web apps in terms of user experience.
> 
> Wicket doesn't come with a client-side validation
> framework by default;
> however, the validators have an opportunity to
> participate in the
> component rendering, so it wouldn't be too tough to
> create your own set
> of validators that also rendered the appropriate
> Javascript to do
> client-side validation.
> 
> > 3. In Valang + Spring MVD, you have all the
> validation
> > code for a form in one place in stark contrast to
> > spreading it in "controller" code as in Wicket and
> > mixing validation code with visual manipulation
> code.
> > Valang's way is much easier to understand and
> > management.
> 
> A Wicketer would view it differently: in
> Valang+Spring MVC you have Java
> code for your controller and validation "code" in
> XML, whereas in Wicket
> it's all in Java code.
> 
> That said, it probably wouldn't be too hard to
> implement a FormValidator
> that accepted valang syntax and applied it to a
> form.
> 
> > So in terms of elegance, productivity, management,
> > ..., I am not sure Wicket's is right.
> > 
> > Can Wicket provide a better solution? 
> > 
> > I would like to share my concern regarding the
> > Wicket's WebPage, where you put a form's code for
> some
> > visual aspects, validation, ajax, etc. in one
> place. A
> > big object. I feel it is too ambitious and it
> looks
> > like spaghetti code and mixes concerns/modules in
> one
> > place. Comment?
> 
> Weird. Your experience is exactly opposite to mine.
> I found Spring MVC
> to be hopelessly scattered: declarations in XML,
> controller code in
> Java, view code in templates. In Wicket, I can
> create self-contained
> components, each including all the functionality,
> markup, validation,
> JS, etc. it needs to get along in the world. I can
> then stitch these
> components together into pages that can be re-jigged
> and reorganized
> very quickly.
> 
> It feels to me like Wicket allows me to work at a
> higher level of
> abstraction, while with Spring MVC I was always down
> in the weeds
> dealing directly with the request/response cycle.
> 
> jk
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



      
____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to