Dick's Wicket comments on episode #371 from the roundup - DRY principle
Lenny P
and Finally, Dick confirms this!
I was always being recommeded to use Wicket as a framework for my new
Web projects.
I tried it out and thought the DRY was violated all over the place,
because of HTML and Java code
is being duplicated for every web page. So, I kept rejecting it, and
been ridiculed for that decision everytime
I talked about it.
I decided to do my web projects in Tapestry 5, which does not violate
the DRY principle.
Finally, someone else mentions the same problem. I was starting to
think I was crazy.
Thanks, DIck!
I literally jumped up and down and yelled 'YES!' when I heard that
comment on the episode :)
Casper Bang
Takeshi Fukushima
I still think Wicket is a joy, compared to so many other stateful web frameworks (JSF in particular is an ivory mega-tower). I don't see DRY violated, I see it as an abstraction layer between (web) designer and (rich widget) developer. However, relying on session-state on the server is just bad bad, so GWT still wins over Wicket in my book.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/-tWA6xXfbCQJ.
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
http://mapsdev.blogspot.com/
Marcelo Takeshi Fukushima
Casper Bang
On Friday, December 2, 2011 7:45:57 AM UTC+1, takeshi wrote:
care to elaborate why? (i mean on why storing the state on the session is bad bad)?
My experience is that developers far too often places things in session scope (JPA entities, heavy DTO chains etc.) and it has two unfortunate observable problems with it. 1) It makes it harder to scale (boxes need to share session-state) and causes the server has to serialize vast amounts of data to disk that may or may not be necessary. 2) It causes timeout issues when the session expires (default 30 min on a Tomcat) which may result in lost work or just generally a bad user experience.
The proper way to think of server state is to use it as a cache (WeakReference's). That is, nice to have for performance reasons, but not strictly necessary for the business logic to function properly. Anyway, that's the conclusion I've arrived at and it causes fewer problems for me.
Fabrizio Giudici
wrote:
> The proper way to think of server state is to use it as a cache
> (WeakReference's). That is, nice to have for performance reasons, but not
> strictly necessary for the business logic to function properly. Anyway,
> that's the conclusion I've arrived at and it causes fewer problems for
> me.
For many reasons I agree with Casper, even though in practice with web
apps I'm finding myself with state on the server.
But I'd like to see some further elaboration on the primary point of this
thread: where does Wicket violate so dramatically DRY? Note that I'm not
necessarily disagreeing (more later eventually), I'd just like to
understand what we're talking about.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it
Robert Casto
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/kO66ryAlEMcJ.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
James Ward
external MongoDB system:
http://www.jamesward.com/2011/11/30/using-mongodb-for-a-java-web-apps-httpsession
My favorite tweet reaction was:
"so wicket's finally webscale?" @evanchooly
https://twitter.com/#!/evanchooly/status/141151958349250560
BTW: There is a way to use Memcached as a distributed and external
second level cache for Hibernate instead of using session:
https://github.com/raykrueger/hibernate-memcached
-James
> <mailto:java...@googlegroups.com>.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com
> <mailto:javaposse%2Bunsu...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
>
>
> --
> Robert Casto
> www.robertcasto.com <http://www.robertcasto.com>
> www.sellerstoolbox.com <http://www.sellerstoolbox.com>
>
> --
> You received this message because you are subscribed to the Google
> Groups "The Java Posse" group.
Lenny P
time in Java code, via panel.add() functions.
This IMHO is a huge violation of the DRY principle as when you change
the web page you have to do it
Both in HTML and in Java code.
By comparison, in Tapestry 5, HTML code is the only place where the
page structure is kept.
On Dec 2, 7:15 am, "Fabrizio Giudici" <Fabrizio.Giud...@tidalwave.it>
wrote:
> On Fri, 02 Dec 2011 09:37:05 +0100, Casper Bang <casper.b...@gmail.com>
> wrote:
>
> But I'd like to see some further elaboration on the primary point of this
> thread: where does Wicket violate so dramatically DRY? Note that I'm not
> necessarily disagreeing (more later eventually), I'd just like to
> understand what we're talking about.
>
> --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> fabrizio.giud...@tidalwave.ithttp://tidalwave.it-http://fabriziogiudici.it
Oscar Hsieh
I don't agree that wicket violates DRY. Wicket does require you to declare your web component on both markup (html) and java class, but personally I think that is no different than interface - implementation class require you to type in the method name twice. Wicket is designed based on the idea that you have web designers working on the look (html and css), while programmers working on the logic (java). Although not every project has luxury to have web designer working on the UI (Mine does not), I still like the fact that I can have clean Java code that is easy to read, debug, test and maintain. Personally I will put Wicket above GWT (sorry Casper).
Thanks
Fabrizio Giudici
> Like Casper said, cache is a better way to cut down database traffic. A
> fat session can cause a lot of problems once the traffic goes up.
>
> I don't agree that wicket violates DRY. Wicket does require you to
> declare
> your web component on both markup (html) and java class, but personally I
> think that is no different than interface - implementation class require
> you to type in the method name twice. Wicket is designed based on the
> idea
> that you have web designers working on the look (html and css), while
> programmers working on the logic (java).
It's my point. If you want to criticize Wicket, please show me a better
way to do that, preserving the separation of the workflows of the two
different professionals (graphic designer and developer) working on
different artifacts.
If you don't need a web designer, Vaadin for instance is ok and it's DRY.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
Ricky Clarkson
Lenny P
> fabrizio.giud...@tidalwave.ithttp://tidalwave.it-http://fabriziogiudici.it
Fabrizio Giudici
> Exactly. Tapestry 5 does exactly this without violating DRY.
And then? After the first round you give it to the web designer. He
changes it with some embellishments. How do you manage next round?
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
Lenny P
structure from the HTML files.
There is no need then to duplicate page structure in java.
On Dec 2, 12:09 pm, "Fabrizio Giudici" <Fabrizio.Giud...@tidalwave.it>
wrote:
> On Fri, 02 Dec 2011 18:00:40 +0100, Lenny P <lpri...@hope.nyc.ny.us> wrote:
> > Exactly. Tapestry 5 does exactly this without violating DRY.
>
> And then? After the first round you give it to the web designer. He
> changes it with some embellishments. How do you manage next round?
>
> --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> fabrizio.giud...@tidalwave.ithttp://tidalwave.it-http://fabriziogiudici.it
btilford
extent this requires you to keep the component structure in both java
and html. Most other frameworks leak the data into your layout which
ends up being much harder to design and maintain even if you don't
have a front-end guru. Another benefit is that you can create re-
usable components that aren't tied to a specific data model.
Reinier Zwitserloot
Lenny P
I have nothing against Wicket, it's a good framework, but it does
violate the DRY principle with it's document structure duplication.
Oscar Hsieh
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
Lenny P
When working with a web designer in the front end you have to use
static structure for your templates no matter
which framework you use, which works for 99% of the cases.
Static structure does not mean the web page is static when rendered
anyway.
When you truly need dynamically generated page, you can do that
In Tapestry easily either without a HTML template or with the dynamic
component which
Tapestry supports - without violation of DRY. Same is true for GWT
with uiBinder.
Just have a completely Java-generated component for your dynamic
section.
On Dec 3, 2:11 am, Oscar Hsieh <zen...@gmail.com> wrote:
> Tapestry can do that because tapestry only supports static page structure.
> So the component path is predictable. This means that you cannot add a
> component to another at runtime. (I never use uiBinder but looks similar)
>
> Check the principal 1.http://tapestry.apache.org/tapestry5/
Richard Kennard
problem of DRY UIs? It's an Open Source project designed for exactly
this.
I talk about it in my JavaOne video here (at 5m.30s):
http://blog.kennardconsulting.com/2011/12/metawidget-javaone-2011-jboss-booth.html
If you get chance to look at it, I'd be most interested in your
feedback.
Regards,
Richard.
Fabrizio Giudici
> That is true but that isn't any kind of a limitation.
> When working with a web designer in the front end you have to use
> static structure for your templates no matter
> which framework you use, which works for 99% of the cases.
> Static structure does not mean the web page is static when rendered
> anyway.
> When you truly need dynamically generated page, you can do that
> In Tapestry easily either without a HTML template or with the dynamic
> component which
> Tapestry supports - without violation of DRY. Same is true for GWT
> with uiBinder.
> Just have a completely Java-generated component for your dynamic
> section.
I don't understand your answer, since you first say that it's true (so,
Tapestry doesn't do that, but "it's not a limitation") and later that
Tapestry in any case does that. Can you elaborate?
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
Lenny P
But it doesn't limit you to it, by using the methods I mentioned.
Static structure just makes is possible for the Web devs to view/edit
HTML code with Dreamweaver etc.
But, you can also do dynamic pages in your Java code if you wish,
or mix the two with blocks/delegates and the Dynamic component.
You can do the same things in GWT. Use uiBinder for you static/semi-
static
parts and Java code for your totally dymanic parts.
Of course, the dynamic parts can't be edited by the web designer
who doesn't know Java...
On Dec 4, 4:54 am, "Fabrizio Giudici" <Fabrizio.Giud...@tidalwave.it>
wrote:
> I don't understand your answer, since you first say that it's true (so,
> Tapestry doesn't do that, but "it's not a limitation") and later that
> Tapestry in any case does that. Can you elaborate?
>
> --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> fabrizio.giud...@tidalwave.ithttp://tidalwave.it-http://fabriziogiudici.it
Fabrizio Giudici
> It's true that the #1 Tapestry principle is static document structure.
> But it doesn't limit you to it, by using the methods I mentioned.
> Static structure just makes is possible for the Web devs to view/edit
> HTML code with Dreamweaver etc.
> But, you can also do dynamic pages in your Java code if you wish,
> or mix the two with blocks/delegates and the Dynamic component.
> You can do the same things in GWT. Use uiBinder for you static/semi-
> static
> parts and Java code for your totally dymanic parts.
> Of course, the dynamic parts can't be edited by the web designer
> who doesn't know Java...
It seems we're discussing about two different meanings of "dynamic".
Unfortunately I stopped using Tapestry long time ago and I don't recall
what I could do with it; but I seem to understand that you haven't a clear
idea of what you can do with Wicket. Maybe I'm wrong, let's see.
Given for sure that we're all meaning "dynamic" in the sense that a page
gets populated by data from Java, the real point is to be able to create a
page out of simpler components composed together. For instance, I can have
a table, a button bar, a detail section, each one with its own Java
structure (that can be tested separately) and the HTML layout (that I can
give to the web designer). I can also have multiple HTML renderings for
each component, if I want, for reusing the component in different
applications. Then I can assemble them together by just instantiating some
Java objects and putting them into a container. Bric is a framework based
on Wicket that works exactly in this way, if I correctly recall.
Can I do this sort of things with Tapestry?
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
Lenny P
Tapestry and Wicket are very similar in this way and most paradigms
apply to both frameworks.
When I say dynamic I mean that you don't know ahead of time which
components get composed to make up the page.
Tapestry components get assembled in the HTML files and there is no
need to repeat this assembly n java code.
On Dec 4, 11:07 am, "Fabrizio Giudici" <Fabrizio.Giud...@tidalwave.it>
wrote:
> It seems we're discussing about two different meanings of "dynamic".
> Unfortunately I stopped using Tapestry long time ago and I don't recall
> what I could do with it; but I seem to understand that you haven't a clear
> idea of what you can do with Wicket. Maybe I'm wrong, let's see.
>
> Given for sure that we're all meaning "dynamic" in the sense that a page
> gets populated by data from Java, the real point is to be able to create a
> page out of simpler components composed together. For instance, I can have
> a table, a button bar, a detail section, each one with its own Java
> structure (that can be tested separately) and the HTML layout (that I can
> give to the web designer). I can also have multiple HTML renderings for
> each component, if I want, for reusing the component in different
> applications. Then I can assemble them together by just instantiating some
> Java objects and putting them into a container. Bric is a framework based
> on Wicket that works exactly in this way, if I correctly recall.
>
> Can I do this sort of things with Tapestry?
>
> --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> fabrizio.giud...@tidalwave.ithttp://tidalwave.it-http://fabriziogiudici.it
Oscar Hsieh
<t:actionlink t:id="makeGuess" context="current">${current}</t:actionlink>or
<t:beaneditform object="address"/>
About the dynamic page, I believe you are talking about doing ajax with blocks and zones. As far as I know you have to trigger the ajax behavior with an action link (or other similar link components), and you can only update one zone per action. That is very limited compare to what you can do with wicket.Also since Tapestry is static, the blocks and zones has to be defined on the page structure (tml) where with Wicket you can add/remove a panel/border to/from a page at runtime.
Not saying Tapestry does not have great ideas, it has many. But the one thing that I really don't like about tapestry is behaviors/logics in the markup
<t:if test="user">
Welcome back, ${user.firstName}
<p:else>
<t:pagelink name="login">Login</t:pagelink> /
<t:pagelink name="register">Register</t:pagelink>
</p:else>
</t:if>I hated it since the day of JSP and will never want to go back again.Finally, there seems to be an effort to resolve this DRY issue
https://issues.apache.org/jira/browse/WICKET-3335
The solution is to queue up the components and then try to resolve them at runtime. It's probably not going to work in all cases specially when components sharing the same id (ex: repeating views).
Thanks
Lenny P
but nobody does.
It's your choice if you want to use <t:if>
Blocks are not just for Ajax/Zone updates.
You can use <t:delegate to="block"> on the static page without Ajax or
Zone,
also, you can update multiple zones from a single Ajax action as well
in Tapestry.
Also, there is a t:dynamic component which can render totally dynamic
part of a page,
and assemble components at run-time.
I don't want to start a war about who's framework is best here.
Obviously wicket does a job that you want, and that's great!
But for my project/ in my experience, Tapestry served me very well
without violating the DRY principle, which Wicket does violate in
this,
small but very prolific/common case.
Ricky Clarkson
Fabrizio Giudici
wrote:
> [image: Screen Shot 2011-12-05 at 7.53.14 PM.png]
>
>
> void f() {
> label:
> for (int i = 0; i < 10; i++) {
> break label;
> }
> }
>
LOL (for the image). But it's not a full goto: works only in the local
scope. It's indeed a more sophisticated break. With a true goto you could
jump everywhere.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
Ben Smith-Mannschott
<Fabrizio...@tidalwave.it> wrote:
> On Tue, 06 Dec 2011 04:54:45 +0100, Cédric Beust ♔ <ced...@beust.com> wrote:
>
>> [image: Screen Shot 2011-12-05 at 7.53.14 PM.png]
>>
>>
>> void f() {
>> label:
>> for (int i = 0; i < 10; i++) {
>> break label;
>> }
>> }
>>
>
> LOL (for the image). But it's not a full goto: works only in the local
> scope. It's indeed a more sophisticated break. With a true goto you could
> jump everywhere.
>
oh?
Can you give me an example of a language that has
procedures/function/methods/subroutines and allows goto to transport
you from the innards of one to another? When you arrive at your
destination without its stack frame ever having been set up, what
exactly would that mean?
void foo(float x) {
goto HERE;
}
void bar(float *x) {
HERE:
*x = 1.0; // BOOM?
}
foo(0.1);
If you *really* want unrestricted goto, look into call/cc, but that's
a whole other can of worms.
// Ben
Reinier Zwitserloot
Fabrizio Giudici
<bsmit...@gmail.com> wrote:
> On Tue, Dec 6, 2011 at 09:18, Fabrizio Giudici
> <Fabrizio...@tidalwave.it> wrote:
>> On Tue, 06 Dec 2011 04:54:45 +0100, Cédric Beust ♔ <ced...@beust.com>
>> wrote:
>>
>>> [image: Screen Shot 2011-12-05 at 7.53.14 PM.png]
>>>
>>>
>>> void f() {
>>> label:
>>> for (int i = 0; i < 10; i++) {
>>> break label;
>>> }
>>> }
>>>
>>
>> LOL (for the image). But it's not a full goto: works only in the local
>> scope. It's indeed a more sophisticated break. With a true goto you
>> could
>> jump everywhere.
>>
>
> oh?
>
> Can you give me an example of a language that has
> procedures/function/methods/subroutines and allows goto to transport
> you from the innards of one to another? When you arrive at your
> destination without its stack frame ever having been set up, what
> exactly would that mean?
Well, BASIC for the simple answer. But also C with setjmp/longjmp:
http://en.wikipedia.org/wiki/Setjmp.h
Yes, setjmp/longjmp is a mess and you can easily kill yourself with it.
But it does exist.
Vince O'Sullivan
> foo:
> System.out.println("hey!");
> {break foo;}
>
> but this isn't a goto. No matter where the label is, 'break X' just means:
> keep aborting out of scopes until you hit the same level as the named
> label. The above code will NOT print 'hey!' twice. Just once.
That just didn't look right, so I had to try it out. It didn't
compile. I assume it should have been the following; (which makes a
lot more sense, particularly with reference to it not printing twice.
1)
foo: {
System.out.println("hey!");
break foo;
}
(It's all in the brackets.)
Lenny P
As for components with the same IDs, Tapestry solved this problem
just fine, so I don't see that Wicket can't.
On Dec 5, 12:47 pm, Oscar Hsieh <zen...@gmail.com> wrote: