For some reason, Roger's reply-to is his email instead of the list. On Thu, 2004-06-17 at 15:28, Ate Douma wrote: > I think there are some responses *lost* on the list. > In the response from Roger I see several included comments from Scott which haven't > been > received on the list (also not in the eyebrowse archives). > But Roger seems to have received them. > Scott, have you mailed roger directly or did we lose something on the list? > > Roger Ruttimann wrote: > > Scott T Weaver wrote: > > > >> On Thu, 2004-06-17 at 11:25, Roger Ruttimann wrote: > >> > >> > >>> David Sean Taylor wrote: > >>> > >>> > >>> > >>>> On Jun 16, 2004, at 6:31 AM, Scott T Weaver wrote: > >>>> > >>>> > >>>> > >>>>> On Tue, 2004-06-15 at 18:28, Ate Douma wrote: > >>>>> > >>>>> > >>>>> > >>>>>> David Sean Taylor wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Jun 15, 2004, at 8:53 AM, Ate Douma wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> To me, this seems to lead to very complex psml though. I would > >>>>>>>> certainly like to see a more > >>>>>>>> simple model implemented first before going that road. > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> Im -1 on nested pages, and +1 on nested fragments (references), > >>>>>>> which > >>>>>>> does not need to be implemented in the first solution > >>>>>>> > >>>>>> > >>>>>> +1 > >>>>>> > >>>>> > >>>>> Also -1 on nested pages. > >>>>> > >>>>> > >>>>> > >>>>>> Nested fragments, but not as references, are already used by the > >>>>>> layout portlets! > >>>>>> > >>>>> > >>>>> I would also like to add support for non-portlet fragments, like raw > >>>>> html, etc. > >>>>> > >>>> > >>>> That would just be a different fragment type, such as "markup" > >>>> These markup fragments will need a deployable model, like decorators > >>>> It first it would seem we lose all the benefits of a portal if we > >>>> put in HTML-specific markup, > >>>> On the other hand, if your PSML pages were markup specific, like > >>>> what J1 currently supports, it makes more sense > >>>> > >>>> > >>>> > >>>>>>>> Probably the same result could be created without page nesting > >>>>>>>> using > >>>>>>>> fragment references. These could > >>>>>>>> reference other pages (pulling in their decorator definitions with > >>>>>>>> them) or fragments within other pages. > >>>>>>>> As far as I can tell, then there would be no need to define pages > >>>>>>>> within pages. > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Fragments do not need to be associated with a page, at least not > >>>>>>> in a > >>>>>>> database implementation > >>>>>>> See the database model for PSML in the J2 CVS > >>>>>>> > >>>>>> > >>>>>> I think if we are going to support non-page based fragments (for > >>>>>> references) > >>>>>> we should also provide a file based implementation. Dunno if you > >>>>>> should still > >>>>>> call it psml then though. > >>>>>> > >>>>> > >>>>> Believe it or not, I am beginning to think the non-RDBMS XML > >>>>> file-based > >>>>> page system is a better approach than the RDBMS one. It fits better > >>>>> into CMS model than an RDBMS page manager does. We could also use VFS > >>>>> to abstract the file system were the pages reside. VFS also > >>>>> supports a > >>>>> WebDAV based file system out the box. > >>>>> > >>>>> > >>>> > >>>> Well it does make some sense and certainly simplifies things > >>>> RDMBS PSML can just be an implementation for those who need it. It > >>>> doesn't need to be implemented first. > >>>> > >>> > >>> +1 Since it is more likely that JCMS will manage the pages. > >>> > >>> > >>> > >>>> For scalable systems, from my experience a more robust Page Manager > >>>> will be required than simply putting the pages on the file system > >>>> with no sharing across nodes > >>>> > >>>> With WebDAV interfaces, we could push all of that logic (locking, > >>>> versioning) back to the CMS Server and not have to deal with it > >>>> That is one of the goals of JCMS > >>>> Perhaps we should look into a VFS-backed JCMS for the WebDAV support > >>>> > >>>> I will try to work on getting JCMS into incubator so that people can > >>>> look at it > >>>> The current base system has a small footprint, and I'd still prefer > >>>> it to go into J2 as a component > >>>> > >>>> > >>>> > >>>> > >>>>>>> I believe the page within a page concept can be easily supported > >>>>>>> via the > >>>>>>> profiler's portal URI space, a CMS-like tree > >>>>>>> > >>>>>> > >>>>>> Using folder semantics you mean? Then I'm +1. > >>>>>> > >>>>> > >>>>> I also think the folder metaphor is the best approach. > >>>>> > >>>>> > >>>>> > >>>>>>>> - Folder or menu elements > >>>>>>>> The Folder concept containing other folders and/or pages could > >>>>>>>> be used > >>>>>>>> to generate menus as proposed by Scott (see 4). > >>>>>>>> Something I'm missing right now is a clear understanding how/where > >>>>>>>> folders are defined. I found the om impl but no usage > >>>>>>>> yet so its something I can't relate to enough yet to really > >>>>>>>> decide if > >>>>>>>> I'm going to like it or not. > >>>>>>>> > >>>>>>> > >>>>>>> Couldn't the Page Manager support the concept of folders in its > >>>>>>> model? > >>>>>>> Im also wondering if the Page Manager should support the JCMS API > >>>>>>> > >>>>>> > >>>>>> One thing at a time please ;-) > >>>>>> Do I understand it now correctly that folders (for a file based > >>>>>> Page Manager) > >>>>>> are simply derived from filesystem folders? > >>>>>> > >>>>> > >>>>> That is how I see it. Or possibly using a VFS file system. > >>>>> > >>>>> > >>>> > >>>> Im still not convinced that VFS should be coupled to Jetspeed > >>>> Prefer coupling at the JCMS level > >>>> I will get some interfaces out on the web today for review > >>>> > >>>> > >>>> > >>>>>> So no definition needed in the psml. > >>>>>> Of course, a DB Page Manager would still require explicit folder > >>>>>> configuration. > >>>>>> > >>>>> > >>>>> That is why I am leaning more towards a page-based system. > >>>>> > >>>>> > >>>>> > >>>>>> If we have folders and pages can't JCMS support be added then "on > >>>>>> top" later? > >>>>>> > >>>>> > >>>>> +1. JCMS may over complicate things in in the beginning. > >>>>> > >>>>> > >>>> > >>>> I don't think so, review the interfaces first before passing > >>>> judgment ;) > >>>> > >> > >> Well, JCMS is just one more thing end users will have to get their head > >> around before they can start using Jetspeed 2. I really don't know how > >> I feel about that. I would be persuaded if some would step up and write > >> some good user docs on how to the two work together. > >> > >> > > > > The two components (page/menu & JCMS) could be developed independently. > > Once the features are stable the page/menus could be integrated into > > JCMS. Reducing the dependencies for the initial implementation helps to > > speed up the J2 development. > > > >> > >> > >>> If we decide to use folders/files structures for the page/menu > >>> implementation the JCMS integration could be done in parallel while > >>> the PSML-2 & rendering is implemented. The definition and the > >>> inital implementation of the inital pages/menu implementation should > >>> not be dependent on JCMS. > >>> > >>> > >>> > >>>>>>>> One important issue I would have with it though is that it wouldn't > >>>>>>>> allow me to render page fragments/portlets in a menu, not > >>>>>>>> external links. > >>>>>>>> Likewise, I don't see how a TabbedPane could be rendered for the > >>>>>>>> current page using the folder > >>>>>>>> concept. > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I believe the tabbed pane could automatically pick up the folder's > >>>>>>> children nodes as its menu options > >>>>>>> This is a valid use case, but not the only use case > >>>>>>> > >>>>>> > >>>>>> I meant in this case a TabbedPane displaying fragments defined > >>>>>> *within* a page. > >>>>>> > >>>>> > >>>>> I don't I like idea of navigating "within" a page. A page should be > >>>>> your final stop, all fragments being rendered at once. > >>>>> > >>>> > >>>> The ability to navigate within a page was a popular feature in J1 > >>>> (the impl caused me endless headaches) > >>>> For example, nested menus where only the selected portlet from the > >>>> fragment set is displayed and all > >>>> other portlets are hidden > >>>> > >>>> I think we could leverage the portlet API to achieve the same thing, > >>>> through maximize mode > >>>> Although nesting maximized portlets is not really supported > >>>> > >>>> > >>>> > >>>>>> You won't have a folder then. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> What about external links, links to other pages... > >>>>>>> Or perhaps the folder is how someone defines a menu > >>>>>>> > >>>>> > >>>>> What about having a special link file that you drop into a folder? > >>>>> Just > >>>>> a plain text file with url in it. You could even go as far as > >>>>> dropping > >>>>> velocity template into a folder to support more complicated menu items > >>>>> and such. > >>>>> > >>>>> > >>>> > >>>> For a external link, I think a menu definition is simpler and easier > >>>> to understand > >>>> This does sound intriguing though, each menu option could have its > >>>> own decorations and style > >>>> > >>>> > >>>> > >>>>>>>> The other proposal from David Taylor was defining new psml menu and > >>>>>>>> menu-item elements which could reference pages, (external) > >>>>>>>> fragments > >>>>>>>> and external links (see 3). > >>>>>>>> I understand Scott didn't like adding additional data structures > >>>>>>>> into > >>>>>>>> the mix (see 4), but I for one would prefer this > >>>>>>>> above the folder/page -> menu concept. AFAIK its way more > >>>>>>>> flexible and > >>>>>>>> probably much easier to understand for a user. > >>>>>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>> And, it isn't that different from the J1 implementation. Recreating > >>>>>>>> the current J1 features for J2 will be relatively easier to do I > >>>>>>>> think. > >>>>>>>> > >>>>>>>> Note: I know the folder concept is not *just* about menus. I'm not > >>>>>>>> opposed to folders in anyway. I just think its > >>>>>>>> to restricted for menu rendering. > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> Can we support both, or is that too confusing to the end user? > >>>>>>> See 4 for the menu xml syntax: > >>>>>>> > >>>>>>> <menu type='folder' url='/myfolder'/> > >>>>>>> > >>>>>>> which would generate a menu based on a folder > >>>>>>> > >>>>>> > >>>>>> +1. I'm all for folder support on this. But not to be restricted > >>>>>> by it. > >>>>>> > >>>>> > >>>>> This was exactly my reasoning for using menu/folder concept. I > >>>>> think a > >>>>> good compromise would be this: standard navigation would be built > >>>>> using > >>>>> the folder concept. However, we can introduce an optional "menu" > >>>>> fragment that would be sourced from a .menu file that contained a > >>>>> standardized xml format (like format proposed above). > >>>>> > >>>>> > >>>> > >>>> This sounds reasonable for folders. > >>>> When the user navigates to a folder, they get the default menu for > >>>> that folder, all nodes within that folder. > >>>> > >>>> However, how would you put a menu on a page? > >>>> This could be solved by not differentiating between folders and > >>>> pages, and treat them all alike. > >>>> Whereas many systems treat pages as leaf nodes, PSML pages could be > >>>> considered as non-leaf nodes like folders. > >>>> > >>>> > >>>> > >>>>> Next we introduce the idea of a navigation renderer that would consume > >>>>> and render either .menu files OR folder/page structures. You could > >>>>> have > >>>>> multiple navigation renders on a final portal page. Renders could > >>>>> also > >>>>> be limited on the number of levels they should render. For > >>>>> example, you > >>>>> could have tabbed renderer at the top of a page, and tell it to only > >>>>> render the first 2 nested levels of folders. Then on the left hand > >>>>> side > >>>>> of the page, we have tree-like menu render that renders from level > >>>>> 3 on > >>>>> down. > >>>>> > >>>>> The navigation renderer gives us a very fine grained control over > >>>>> how we > >>>>> render our navigation and separates the model (.menu or folders) from > >>>>> the view. > >>>>> > >>>>> Custom ordering of navigation could be done by storing item order in > >>>>> user preferences. > >>>>> > >>> > >>> Why introducing .menu files if it could be defined in a folder? I > >>> prefer to keep the syntax as simple as possible. > >>> > >> > >> +1 > >> > >> > >>>> Where is the renderer defined, in the fragment or menu? > >>>> This seems very cool but a bit complicated > >>>> > >> > >> Neither, since rendering is a look and feel/view concern you would code > >> it directly into the layout template, i.e. directly into > >> decorations/layout/jetspeed/jetspeed_top.vm > >> > >> > >> > >>>> The part that Im trying to solve is how can the user clearly define > >>>> menus > >>>> If we are introducing renderers and implementation details into the > >>>> mix, I think it confuses the simplicity of the model > >>>> > >>> > >>> I agree that the mix of rendering and implementation is a bit too > >>> complicated. Different levels of rendering migth confuse more than it > >>> helps to create menus. > >>> > >> > >> > >> How about adding a renderFolder(Folder, String) method to > >> JetpseedPowerTool? > >> > >> (in you layout template) > >> $jetspeed.renderFolder(myFolder, "tabbed_folders.vm") > >> and just let the template do the rendering. > >> > >> > >> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
