Re: Is there will be any Tapestry5 + AngularJS integration?

[Kalle Korhonen <ka...@gmail.com>]

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 <
thiagohp@gmail.com> wrote:

> On Tue, 21 May 2013 22:18:40 -0300, Howard Lewis Ship <hl...@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-unsubscribe@tapestry.apache.org
>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>