My suggestions below... On 25/11/2012, at 10:42 PM, bigcache1 wrote:
> I have started to work on my new application, that would address thought > work. > And single page design is very appealing to me. I am heavily inspired by > Asana <http://asana.com> example. > What is main feature of single page design for me? It is a seamless > experience. Because page reloads, are not natural, they only eat time. > Actually, any loads eat time. > These are my first thought design considerations, after 1,5 year Tapestry5 > experience, and reading Igor's book. How I imagine page/component aspect of > the app design: > 1) Pages. Only one page. Index. > 2) Components. Few rich behavior pane components, like the main pane on > tapestry.apache.org, or like panes in Asana. Load them through zone. > This is the sketch of what I have now: > <page> > <menu, which is the mainZone controller> > <mainZone, with components> > <pane-like component> > subzones and smaller components (visually) > </pane-like component> > ...may be additional components and zones here... > </mainZone> > ...may be additional components and zones here... > </page> In the following link, each menu option is a single page, but it's not a big step to turn them into components in just one page. http://jumpstart.doublenegative.com.au/jumpstart/together/withlayout2/gracefulajaxfiltercrud/persons I haven't tried the single page approach with anything complex in Tapestry so I don't know how pleasant it would be doing without onActivate(...) and onPassivate(). You will have to consider problems like how to make views bookmark-able. You'll also lose the browser's Back button functionality because when all your calls are AJAX there's no browser history. Perhaps a mixin on each link and submit could create a bookmark URL and push it to the browser history. > 3) API. Also, I like the idea of API that could work for both internal and > external use, and I'm wondering how to implement that with Tapestry, and > practices are known? Should I go check REST extensions? > 4) Architecture. I'am want to roll out server-side software, and have > different client applications: web-app, mobile app, desktop app. I see > client applications using the same API for data syncing, and event-driven > interaction. I'd go with Tapestry for web tier (client and server) and EJB3 for business tier. That gives you a business tier you can access easily from multiple front-ends. If you need web services, use Tapestry or tapestry-resteasy in front of he business tier. http://jumpstart.doublenegative.com.au/jumpstart/examples/ws/webservicesmore If your front end is mobile it may be Tapestry or, say, jQuery Mobile to web services, or iOS app to web services. If your front end is a desktop app, it could reach the business tier on a LAN with RMI, or remotely by RMI over HTTP, or remotely via REST, etc. etc. I have used all the elements of this architecture and marvelled at its modularity and the ease with which you can use it to build up robust, flexible systems. > Post Scriptum: > Discussion. If discussion will turns out beautiful, I will be glad to > contribute to the Tapestry community, by organizing it into an article, > which could be published on any Tapestry broadcasting channels, as a guide > or FAQ. > Me. I believe I have short, but intense developer experience. I do OOP for 3 > years, Java for 2 years, Tapestry for 1 year. I know few patterns like CoC, > I like the idea of small testable pieces of whatever, maybe I understand the > REST idea. I am trying to live and work by KISS, YAGNI, DRY principles. > Also, think global, act local. > > > > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/SinglePage-app-design-thoughts-tp5718264.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
