If the only difference is how it is rendered, this should really be handled in the renderer, and not the component.
UICommand is the non-rendering part of button and link components. Not sure how helpful it will be to you. It probably depends on how cleanly the original components were implemented. But it does sound like you only want to add a new renderer rather that recreating the whole component. You could use a delegation pattern to delegate your rendering to HtmlOutputLink instead of HtmlCommandLink . On 4/6/06, Jesper Pedersen <[EMAIL PROTECTED]> wrote: > Hi. > > >What is being an HtmlOutputLink subclass providing you? Or for that > >matter, what does HtmlCommandLink provide? Does it maybe make more > >sense to provide this as a single UICommand subclass with alternate > >renderers? Again, I'm completely ignorant about this component, so > >there's probably more to it than that. > > HtmlOutputLink will render the URI directly in the 'href' attribute; > > <a href="/mydir/myfile.jsf">My File</a> > > where HtmlCommandLink will not render the URI but use linkdummyform for > navigation; > > <a href="#" ....>My File</a> > > The 'problem' is that web-crawlers can't use linkdummyform and therefore the > links on the site won't be picked up. > > HtmlCommandLink provides a lot more dynamic functonality than HtmlOutputLink, > but when site indexing is more important then you have to use HtmlOutputLink. > > Also site with 'static' pages doesn't need to use HtmlCommandLink for > navigation -- a static reference to the page plus optional parameters are > enough. > > I havn't look into the UICommand idea -- I just took a copy of > custom.navigation and started hacking ;) > > Best regards, > Jesper > > P.S. Please, Cc: me since I'm not on the list > >
