Navigation in Seaside

Hello,

I'm the creator of Weblocks[1]. Many of the ideas behind Weblocks were
borrowed (or stolen, depending on your point of view) from Seaside.
I'm a little uneasy about the way Weblocks does navigation, so I
wanted to see if I can borrow some more ideas from the Seaside
framework.

At the moment Weblocks has a navigation widget (component), which is a
class that contains a dictionary of pane names and other widgets, as
well as the currently selected pane. When the navigation is rendered,
the currently selected pane is rendered along with navigation links.
Cliking on a particular link resets the current pane. This system is
tied to a friendly URL system, so that a URL path is broken into
tokens and the framework automatically selects appropriate panes.

This system works, but it's somewhat quirky. I can't quite put my
finger on where I went wrong with the design, but there is some
inelegance which I can't resolve.

Could someone point me to information about how Seaside handles this?
I couldn't easily find any online. Thanks in advance!

Regards,
Slava Akhmechet

[1] http://common-lisp.net/project/cl-weblocks/
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Slava,

sorry for not replying such a long time.

>  At the moment Weblocks has a navigation widget (component), which is a
>  class that contains a dictionary of pane names and other widgets, as
>  well as the currently selected pane. When the navigation is rendered,
>  the currently selected pane is rendered along with navigation links.
>  Cliking on a particular link resets the current pane. This system is
>  tied to a friendly URL system, so that a URL path is broken into
>  tokens and the framework automatically selects appropriate panes.

Seaside also has a navigation component (or widget), that is
essentially implemented the same way. It has several concrete
subclasses (depending on the version of Seaside) that either renders
it as an list of links or a select form. With CSS the widget is then
styled to look like a tab-panel for example.

We do not do have the "friendly URL system" though. Just out of
curiosity: How do you handle conflicts in the URL, when multiple
navigation widgets appear on the same page?

>  This system works, but it's somewhat quirky. I can't quite put my
>  finger on where I went wrong with the design, but there is some
>  inelegance which I can't resolve.

I don't see anything wrong with the design, except that maybe the
model should be better separated. In the AJAX/JavaScript package we
have more sophisticated tab panel implementation. It has its own
navigation-item class, that implements functionality for enablement,
visibility and closing of the navigation item. There are several
subclasses for concrete implementations like AJAX driven accordion,
carousel, tab panel, etc.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Lukas,

On Tue, Apr 8, 2008 at 2:09 AM, Lukas Renggli <[hidden email]> wrote:
>  sorry for not replying such a long time.
It's no rush :)

>  We do not do have the "friendly URL system" though. Just out of
>  curiosity: How do you handle conflicts in the URL, when multiple
>  navigation widgets appear on the same page?
At the moment we don't. If someone adds more than one navigation at
the same depth level on the widget tree, the behavior is undefined.
We're refactoring the navigation widget so we're trying to figure out
how to solve this problem. I think the best option so far is to allow
only one navigation widget per depth level to consume URI tokens.

>  I don't see anything wrong with the design
That's probably because you don't map the component to URLs. If you
did, you'd encounter the problem you mentioned above. Another problem
is temporarily replacing the root of the tree with a "dialog" page
that's later expect to return by invoking a continuation. The problem
with doing this is that when I replace the root, the navigation
widgets are gone and the URL the user is at (/foo/bar) becomes
invalid, so the server sends a 404. One way to solve this is to
temporarily redirect to '/', but this seems somewhat hackish.

I wanted to get an idea of what Seaside folks think about these issues.

BTW, I really like Magritte. I designed a similar system[1] for
Weblocks thinking I did something original. Oh well, there's nothing
new under the sun :)

- Slava

[1] http://www.defmacro.org/ramblings/ui-dsl.html
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/4/9, Vyacheslav Akhmechet <[hidden email]>:
We don't do automatic URL management so we don't have such problems.
Really, the problems outlined here very basic and just the tip of the
iceberg.

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

On 4/10/08, Philippe Marschall <[hidden email]> wrote:
>  Really, the problems outlined here very basic and just the tip of the
>  iceberg.
I don't think that's true. I didn't encounter other problems, and
things work rather well. It's definitely a little tricky, but I
believe it's a good idea that can be very useful if implemented right.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside