Home Link

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Home Link

Zulq Alam
Hi,

I've been trying to implement a way for any component or task to send
the user to the root page, i.e. home. I'm having some difficulties.

I have added an instance variable 'root' and #root which returns the
current component as the root if #root:aComponent has not already been
sent. This is in the superclasses to all my components and tasks which
extend WAComponent and  WATask respectively.

root
    ^ root ifNil: [root := self]

root: aComponent
    root := aComponent

So, before I call any component I pass the current root to the called
component.

self call: (aComponent root: self root)

Assuming all the components I call understand what to do with a root
then at any given time a component will have a reference to the root
component via "self root".

Now, a link home takes a simple form.

html anchorWithAction: [self root home] text: 'Home'

And this seems to work fine. I don't appear to be able to call home from
a Task though.

go
    self root home

# PFView(Object)>>doesNotUnderstand: #owner

    self    a PFView
    temps
    aMessage    owner
    inst vars
    decoration    a WAStateHolder(a PFView)
    root    a PFView

I've attached the full stack trace from the call to #renderContentOn of
the Task.

I'm not sure what I'm doing wrong, any help would be appreciated.

Thanks,
Zulq.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Home Link

Zulq Alam
Sure I have.

Zulq Alam wrote:
>
> I've attached the full stack trace from the call to #renderContentOn
> of the Task.


# PFView(Object)>>doesNotUnderstand: #owner

    self a PFView
    temps
    aMessage owner
    inst vars
    decoration a WAStateHolder(a PFView)
    root a PFView

# PFView(WAComponent)>>removeDecoration:

    self a PFView
    temps
    aDecoration a WADelegation
    dec a PFView
    inst vars
    decoration a WAStateHolder(a PFView)
    root a PFView

# WADelegation(WADecoration)>>remove

    self a WADelegation
    temps
    inst vars
    next a WAStateHolder(a PFView)
    delegate a PFLogInTask

# [] in PFView(WAComponent)>>show:onAnswer: {[:v | delegation remove. event remove. aBlock value: v]}

    self a PFView
    temps
    aComponent a PFLogInTask
    aBlock an AnswerContinuation
    delegation a WADelegation
    event a WAAnswerHandler
    v a PFLogInTask
    inst vars
    decoration a WAStateHolder(a PFView)
    root a PFView

# WAAnswerHandler>>handleAnswer:continueWith:

    self a WAAnswerHandler
    temps
    anObject a PFLogInTask
    aBlock [] in WAAnswerHandler(WADecoration)>>handleAnswer: {[^ false]}
    inst vars
    next a WAStateHolder(a PFLogInTask)
    event nil
    block [] in PFView(WAComponent)>>show:onAnswer: {[:v | delegation remove. event remove. aBlock value: v...etc...

# WAAnswerHandler(WADecoration)>>handleAnswer:

    self a WAAnswerHandler
    temps
    anObject a PFLogInTask
    inst vars
    next a WAStateHolder(a PFLogInTask)
    event nil
    block [] in PFView(WAComponent)>>show:onAnswer: {[:v | delegation remove. event remove. aBlock value: v...etc...

# [] in PFLogInTask(WAComponent)>>answer: {[:ea | ea handleAnswer: anObject]}

    self a PFLogInTask
    temps
    anObject a PFLogInTask
    ea a WAAnswerHandler
    inst vars
    decoration a WAStateHolder(a WAAnswerHandler)
    root a PFView
    logInView a PFLogInView

# PFLogInTask(WAComponent)>>decorationChainDo:

    self a PFLogInTask
    temps
    aBlock [] in PFLogInTask(WAComponent)>>answer: {[:ea | ea handleAnswer: anObject]}
    inst vars
    decoration a WAStateHolder(a WAAnswerHandler)
    root a PFView
    logInView a PFLogInView

# PFLogInTask(WAComponent)>>answer:

    self a PFLogInTask
    temps
    anObject a PFLogInTask
    ea a WAAnswerHandler
    inst vars
    decoration a WAStateHolder(a WAAnswerHandler)
    root a PFView
    logInView a PFLogInView

# [] in PFLogInTask(WATask)>>renderContentOn: {[self answer: self go]}

    self a PFLogInTask
    temps
    html a WAHtmlRenderer
    inst vars
    decoration a WAStateHolder(a WAAnswerHandler)
    root a PFView
    logInView a PFLogInView

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Home Link

Yanni Chiu
In reply to this post by Zulq Alam
Zulq Alam wrote:
> I've been trying to implement a way for any component or task to send
> the user to the root page, i.e. home. I'm having some difficulties.

You should have a look a ShoreComponents.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Re: Home Link

Zulq Alam
I've had a quick look at Shore, I can see there is some root/parent
passing going on in ShoreComponent but no classes in Shore seem to be
Tasks by either extending WATask or ShoreTask.

My problem is the call to self root home works fine from a Component but
fails when called from a Task.

I'm not exactly sure what I should be looking for in Shore? Is there an
example of a Task redirecting to home that I'm missing somewhere?

Thanks,
Zulq

Yanni Chiu wrote:

> Zulq Alam wrote:
>> I've been trying to implement a way for any component or task to send
>> the user to the root page, i.e. home. I'm having some difficulties.
>
> You should have a look a ShoreComponents.
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Home Link

Yanni Chiu
Zulq Alam wrote:
> I've had a quick look at Shore, I can see there is some root/parent
> passing going on in ShoreComponent but no classes in Shore seem to be
> Tasks by either extending WATask or ShoreTask.
>
> My problem is the call to self root home works fine from a Component but
> fails when called from a Task.
>
> I'm not exactly sure what I should be looking for in Shore? Is there an
> example of a Task redirecting to home that I'm missing somewhere?

What behaviour are you trying to achieve with a WATask?
If you're just trying to get a "normal" web browsing
experience, then have a look at how ShoreDemo1Root is
the "root" component from which other components are called.

FWIW, I've been down the WATask path, following the Sushi
store demo. Web apps seem to flow in two ways at the same
time. One is just random browsing, and the other is a
constrained path. You could consider "random" browsing
to be a contrained path, and therefore wrap it in a task,
but IMHO it makes the code harder.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Re: Home Link

Zulq Alam
I kind of agree but it seems WATask is doing more than just
encapsulating workflow.

I wonder what purpose this redirect serves?

renderContentOn: html
    self session redirectTo: (html urlForAction: [[self answer: self go]
repeat])

And why should local decoration wrap new delegations (the answer to this
will likely go over my head at the moment) rather than vice versa in
WAComponent?

decoration: oldDecoration shouldWrap: newDecoration
    ^ (oldDecoration isGlobal and: [newDecoration isGlobal not])
        or: [oldDecoration isLocal and: [newDecoration isDelegation]]

I'd like to understand these before I stop using WATask for my short
workflows. Also, for long workflows I still have the same problem.

Where I don't agree is I think when the application scales having
followed a consistent pattern and separating these concerns will have
maintenance benefits.

Z.

Yanni Chiu wrote:
>
> FWIW, I've been down the WATask path, following the Sushi
> store demo. Web apps seem to flow in two ways at the same
> time. One is just random browsing, and the other is a
> constrained path. You could consider "random" browsing
> to be a contrained path, and therefore wrap it in a task,
> but IMHO it makes the code harder.
>

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside