Aida/Web Implementing back links?

Janko -

A nice extension to your tutorial would be to enable editing of the
addresses - so I set about doing this.

I changed my addressApp view to have:

        e cell addText: 'Name: '. e newCell add: ((WebInPlaceEditableText
aspect: #name for: self observee)
                triggerElement: ((WebImage gif: #buttonEditGif) title: 'Edit this
text') ). e newRow.


It looks a bit cramped with the edit button - but can sort that
formatting out (and neat how so few lines of code give you instant in
place editing).

However I am not sure how best to implement a way to get back from my
address to the address list.

I want to put something like: e cell addLinkTo: self observee parent
text: 'Back to Address Book'.

But my addresses don't have a parent attribute. Is this the right way
to do this (put back links in your model) or does Aida have some
navigation object that stores where I have navigated to?

I think the above questions/examples would add a little closure to you
tutorial (and maybe how to best update the left navbar too).

Tim

Hi Tim,

TimM wrote:
Yes, that's an obvious and correct way to go.

> But my addresses don't have a parent attribute. Is this the right way
> to do this (put back links in your model) or does Aida have some
> navigation object that stores where I have navigated to?

No, back links are a responsibility of domain model. I updated tutorial
to have a parent instvar in Addresses.

> I think the above questions/examples would add a little closure to you
> tutorial (and maybe how to best update the left navbar too).

Forms and editing are next step to add to my tutorial, on classic way
for the start and then your's Ajax in-place editing way, just to feel
the taste of Ajax a bit. Excpect this soon.

Just for info: navbar is defined in WebStyle, protocol 'frame
navigation', #navigationBarElement and other methods ...

Best regards
Janko

Hi Janko,

>> But my addresses don't have a parent attribute. Is this the right way
>> to do this (put back links in your model) or does Aida have some
>> navigation object that stores where I have navigated to?
>>
> No, back links are a responsibility of domain model. I updated
> tutorial to have a parent instvar in Addresses.


I am torn on this one - having a parent in an Address feels quite unnatural
to me - very rarely do my models have that "parent" attribute? The cross
linking can cause GC problems and I have a hunch it makes it tricky (I'm
not sure though) for things like Glorp (relational database mapper) to work
as well.

On the other hand - if you bookmark some arbitrary address, the back link
wouldn't work if you later came back to that address, unless you have the
parent attribute.

I still would be tempted to have a Navigation object for some things where
parent feels unnatural though - and in my viewXXX where I interacted with
the Navigation, if the lastVisited attirbutue was nil I would render a redirect
to the root of the model.

Is this kind of thing doable, can I override some method in the framework
and pass this kind of object through to the ViewMethods (best) or put it
in a context somewhere?

On a similar note - in the viewXXXX methods, I am suprised you don't pass
in the observer (e.g. viewXXXX: anObserver) - it would get rid of the repeated
self observer stuff in those methods (and is easier to test too).

Tim

Hi Tim,

macta wrote:
>> No, back links are a responsibility of domain model. I updated
>> tutorial to have a parent instvar in Addresses.

> I am torn on this one - having a parent in an Address feels quite
> unnatural to me - very rarely do my models have that "parent" attribute?
> The cross linking can cause GC problems and I have a hunch it makes it
> tricky (I'm not sure though) for things like Glorp (relational database
> mapper) to work as well.
>
> On the other hand - if you bookmark some arbitrary address, the back
> link wouldn't work if you later came back to that address, unless you
> have the parent attribute.

That's the exact reason I prefer back references in domain model, even
that this introduce other problems like maintenance of that links and
sometimes even GC problems as you said. I tried other means like finding
parent from past requests, but all those approaches end to be unreliable.

Ok, for simple one-level hierarchy (as we have in tutorial) you can
store parent object somewhere else (see AIDASite user services for
Discussions, they are accessible from your app: self site discussions).

> I still would be tempted to have a Navigation object for some things
> where parent feels unnatural though - and in my viewXXX where I
> interacted with the Navigation, if the lastVisited attirbutue was nil I
> would render a redirect to the root of the model.

I did that once upon a time with help of WebSession requests, which
stores history of web requests and I then found out from which parent a
request for my child came. But this was unreliable as I already said.
>
> Is this kind of thing doable, can I override some method in the
> framework and pass this kind of object through to the ViewMethods (best)
> or put it in a context somewhere?

Put it in WebSession object, or maybe in WebApplication to be inside the
scope of just that object.

> On a similar note - in the viewXXXX methods, I am suprised you don't
> pass in the observer (e.g. viewXXXX: anObserver) - it would get rid of
> the repeated self observer stuff in those methods (and is easier to test
> too).

Isn't 'self observee' easier to write than 'anObserver' :) Also name of
view method is easier to write and read without parameters IMHO. And
because we have observee as instvar in our apps, I really don't see the
reason for your suggestion.

Notice also that there is an instance of your App for every domain
object on every user session.

Janko

Tim, Janko,

> I am torn on this one - having a parent in an Address feels quite
> unnatural  to me

Just a thought, but if the natural structure of the domain model doesn't have
links from addresses to their owners, then why is it appropriate to structure
the website in a way that needs such links ?  What meaning do those links
express ?

I think what you are trying to do is to provide /navigation/ links, rather than
semantic ones.  Links that are no more connected to the domain model than the
Back button in the browser.  In fact that's an exact parallel -- the navigation
links are part of the "application" (as seen by the user).

As such, it seems to me that the data defining such links -- "up", "back",
"next" -- has to be part of the web application and/or session and independent
of the model.

    -- chris

Hi Chris, Tim,

Chris Uppal wrote:
> Just a thought, but if the natural structure of the domain model doesn't have
> links from addresses to their owners, then why is it appropriate to structure
> the website in a way that needs such links ?  What meaning do those links
> express ?

Navigation links are very important help to user so that he don't feel
lost in an information space. Such links are therefore a must, even that
browser has its own back button etc. navigation support. Usually you
need vertical (hierarchical) and horizontal (next, previous) navigation
links.

> I think what you are trying to do is to provide /navigation/ links, rather than
> semantic ones.  Links that are no more connected to the domain model than the
> Back button in the browser.  In fact that's an exact parallel -- the navigation
> links are part of the "application" (as seen by the user).

Agree, but how to achieve that without domain model help?

> As such, it seems to me that the data defining such links -- "up", "back",
> "next" -- has to be part of the web application and/or session and independent
> of the model.

Consider such an example:

- your adddress web page has up, next and previous links
- you e-mail url of that page to your friend
- he opens that page in his browser - a new session is opened
   and no previous knowledge about address parent exist.

Question is, how will you provide up,next,prev navigation without domain
model support in such a case?

Janko

[Sorry for the long delay before replying.]

Janko, Tim,

> Question is, how will you provide up,next,prev navigation without domain
> model support in such a case?

That's a very good question ;-)

One possible approach would be to make model navigation part of the
presentation layer (almost akin to using CSS).  The web application (or
something associated with it) could provide some sort of abstraction which the
HTML rendering would convert into up/left/right links.  Something similar to
(or perhaps even identical to) a TreeModel which would map from domain objects
to parents/children/siblings using domain links where they were available, or
other (pluggable?) mechanisms where that info isn't part of the domain.

The alternative seems to be that the "domain" objects turn into representations
of web pages, rather than the other way around.  So one might end up with two
layers of "model" -- the "real" model plus a collection of presentation-level
objects which roughly follow (or could be considered to be enhanced
proxies for) the real model's structure.

I'm not advocating the TreeModel idea, BTW, let alone requesting it as an
enhancement to core Aida.  Just thinking aloud.

    -- chris