You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by wa...@wispertel.net on 2005/02/23 06:26:28 UTC

Re: [jira] Commented: (JS2-69) Finallizing Portal Navigation usingthe Profiler

> ... For the Portal Navigation solution(s), I very much would like to see a
> similar strategy be used. Determine a few (at the most) very simple
Navigation styles and
> build that as small,light and fast components. Once that would be in
place, more powerful
> enhanced components can be created for handling the more complex
solutions like the
> ones we have right now...

I understand your aim here and am generally supportive of your ideas. An
equally important requirement is to isolate the logic from the underlying
PSML content implementation, (file system/XML, DB, CMS, etc.).

Still, the biggest question remains: what is that set of minimal solutions
we want to provide? We have three proposed or existing implementations so
far:

- XML based menu definitions,
- regex path set menu definitions, and
- the existing page relative navigation set.

I am guessing that these could be broken into multiple components that
share  a common base implementation that facilitates interaction with the
profiler and folder/document representations, (where security is
implemented). I think the the primary reason to break these features into
separate modules/components will be to avoid unnecessary/unused computed
results.

The only wrinkle here is that it might be interesting to use multiple
components simultaneously. For example, top level navigations might use an
XML menu definition and page relative sibling folders and pages could be
used for deeper levels in the site beyond the top few folders.

Another question is whether the various approaches can be unified under
one API for use by the layout templates. I am still pondering this, but on
the surface it seems that it might just add more confusion than it is
worth. If the API becomes too generic, (like simply providing all profiled
pages and folders in one big graph/hierarchy), all of the layout logic
will simply end up moving into the templates... I do not think we want
that, (or do we)?

In the end, we might need to avoid doing ANY navigation computation in
advance and defering it alltogether until the layout templates actually
request a particular navigation elements set. I am not sure how that would
be best implemented as individual components.

Still thinking!

Randy


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org