So.. what's the current best practice/front-runner for AngularJS integration? I see several users, Michael Wyraz to name one, have tipped their toes on AngularJS but I didn't find any sample sample apps, much less definitive libraries on Github or elsewhere. There are several areas where a small integration library would be able to help making them both work together seamlessly.
Kalle On Tue, May 21, 2013 at 7:10 PM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Tue, 21 May 2013 22:18:40 -0300, Howard Lewis Ship <hls...@gmail.com> > wrote: > > That's OK; that's the future direction of all web applications, >> > > 1 year in the futre? 5? 10? > > I don't see that coming, at least not for most of webapps. Single page > webapps are good for desktop-like stuff but awful for search engines, which > are vital for public-facing stuff. > > andsupporting that should be the principle goal going forward, even if it >> >> means that much of the T5 infrastructure (pages, components, server-side >> state, etc.) becomes somewhat vestigial >> > > As long as they still work as they (pages, components, etc) work as they > do now, I see no problem in that. That's the most mature part of Tapestry, > having gone through some major internal revisions already (page pool, page > pool not used anymore, performance improvements) already. AJAX is one of > the less mature parts and everything that improves that is a good thing > IMHO. > > > I have some ideas for having a very well integrated api approach, that >> would be on-par with pages and components. That will probably have to >> wait for 5.5. Basically, page-like objects that represent API end points >> and >> support injection, but lack the complexity of Tapestry pages. >> > > What would be the improvements over a page without a template? I'm not > familiar with this part of the Tapestry code. > > For these page-like objects: what about an 'endpoints' subpackage, as we > have now for pages, using the same routing rules? The less new logic we add > and the most we reuse, the better. Or put them in the 'pages' package and > we just use an annotation to tell that specific class is an endpoint and > not a full-blown page. > > > We'd still support live class reloading and maybe a bit of magic in terms >> of how >> incoming requests are routed, parsed to JSON or Java objects, and then >> how responses are generated. >> > > Live class reloading is a major selling point of Tapestry (maybe the > biggest one) so it should be kept for pages, components, mixins and these > new endpoint objects. > > > -- > Thiago H. de Paula Figueiredo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > >