I'm nodding enthusiastically as I read Kalle's comments. He's right - the
differences between being in an authenticated state and non-authenticated state
are so significant and it simplifies matters if a page can assume it is dealing
with just one state or the other. I should have mentioned this special case
earlier.
As an aside, another special case exists: where the components are deep in
different parts of the page's tree of components and "acting quite
independently". In this case a "pub-sub" mechanism could be better than "bubble
up and call down". If the subscribing component has enough state info available
to be able to generate a zone, then server-side pub-sub might suffice...
https://github.com/anjlab/anjlab-tapestry-commons/blob/master/anjlab-tapestry-commons/src/main/java/com/anjlab/tapestry5/services/events/Publisher.java
...otherwise you'd need client-side pub-sub. Today you'd have to write that
yourself. It's discussed here...
https://issues.apache.org/jira/browse/TAP5-2383
Geoff
On 15 Oct 2014, at 5:56 am, Kalle Korhonen <kalle.o.korho...@gmail.com> wrote:
> On Tue, Oct 14, 2014 at 11:11 AM, George Christman <gchrist...@cardaddy.com>
> wrote:
>
>> Commented inline
>> On Tue, Oct 14, 2014 at 12:15 PM, Kalle Korhonen <
>> kalle.o.korho...@gmail.com
>>> wrote:
>>> On Tue, Oct 14, 2014 at 8:18 AM, George Christman <
>> gchrist...@cardaddy.com
>>> wrote:
>>> My original response still stands and I know what you are trying to
>>> accomplish but it gets tricky trying to get it all done asynchronously,
>> and
>>> in general I advice to just handle sign-in/sign-up via a full page
>> refresh.
>> I really do like the smooth user experience async can provide to the end
>> user, but I guess it might just be easier to do a full page
>> refresh in most cases. There is one use case where the user fills in a form
>> prior to login and I would like to keep the login async if possible. It
>> helps prevent me from
>> having to store the object into memory while they are being authenticated.
>>
>
> Yes, I perfectly understand that desire. Just saying because I've been down
> on that path before and ended up shooting myself in the foot and in
> retrospect, it would have been much easier in my case to accept the full
> page refresh and spend the development capacity on increasingly complex
> implementation for async authentication on something else.
>
>
>>>
>>> Just as an anecdotal evidence and totally IMHO, stackoverflow.com has
>> one
>>> of the best designs out there for sign-in/sign-up flows and they are
>> doing
>>> it as a separate page as well.
>>>
>> I plan to borrow a few ideas form them, they do a nice job. I just hate
>> having to leave a page to come back to it. Just seems cumbersome.
>>
>> Does the security framework have the ability to redirect the user back to
>> the original page they were on prior to clicking the login link rather than
>> say account home?
>> Example of desired behavior, I'm looking at my listing, but decide I want
>> to edit the listing. I click the nav sign in link and it redirects me to
>> the login page. Once I'm logged in, I'd like to be redirected back to the
>> listing page rather than the account landing page. This was one of the
>> reasons I liked the async approach.
>>
>
> Yes, Tynamo's tapestry-security does - within a reason and the support for
> it was enhanced in the latest version. For example, even if your edit link
> was async, the security framework would automatically store a page render
> link for the listing page.
>
> Kalle
