Yes, we have a domain model which talks to stateless backend services. The "controller", i.e. the application flow and event handling is in the pages. We used to have a different architecture with Spring Webflow (that was in the dark ages of JSF) as the "controller". Since we're building a single app, we haven't found it necessary to abstract these control flows out of the pages. Your mileage may vary if you're trying to reuse the workflow across multiple clients.
<sermon> On the topic of patterns I have a favourite quote from a golf istruction book: "the best golf swing is one that gets the ball into the hole in the fewest strokes". The patterns you find in books are solutions that worked in the past for other people. Look at them and decide if they work for your particular problem. If you can't decide, you don't understand your problem domain yet. </sermon> cheers, Thomas On Wed, Jul 2, 2008 at 9:30 AM, marco m <[EMAIL PROTECTED]> wrote: > > > > Thomas Mäder wrote: > > > > Wicket is a framework to write (mostly) statefulweb pages. Unlike other > > web > > frameworks it does not impose a particular way to structure the > > application > > logic beyond that. Think of it like, say, the QT widget set. It's a way to > > display information and to be notified of user interactions. > > > > Thomas > > > > PS: when did the notion start that design pattens had an intrinsic value? > > "Now new and improved with more patterns!" Patterns are ways to structure > > code WHEN IT NEEDS STRUCTURING. A HelloWorld app DOES NOT NEED PATTERNS. > > (sorry for the shouting, pet peeve) > > > > > > I hear you Thomas. Maybe I should ask the question another way...does > anyone out there encapsulate their data access layer/service layer within > their model or do people put that stuff in their pages/components? Is anyone > using any patterns? if not...i feel so last year! > -- > View this message in context: > http://www.nabble.com/patterns-for-web-ui-apps.--mvc-models-tp18214140p18231819.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
