David Sean Taylor wrote:
> Team,
>
> Im sorry for my unexcused absence.
> Been finishing off a book for Manning (Portlets in Action) and the last 10
> days have been basically write, eat, write, write, sleep, write ...
> Also had a project deadline mixed in there
No problem ! When your book will be available ?
>
> In the book, I wrote about Graffito
Thanks !
> I had limited time, and I followed a pattern I used on my project:
>
> * override the Graffito interfaces that I needed
> * don't use the pluggable persistence architecture
> (i found this too complicated for my time alloted)
>
Maybe some sequence diagrams should help. I think it is not so complex. Let me
know when you want to speak about that.
> Not perfect, but at least we are now going to be in print soon
>
> So I overrode:
>
> ContentModel - store content on file system + relational DB for metadata
> ContentSearch - integrated with Lucene, worked great
> ContentServer - provide Graffito normalized URI
>
> I *know* this didn't follow our architecture completely, but at least I got
> back to using Graffito again.
I think it follows our architecture. Maybe we can try to move your code into
the persistence layer. The persistence layer is just there to give more
abstraction on the content repo.
I like the idea to split between a fs and a database. I'm also interesting to
have more normalization on the uri.
is it possible to send me your code snapshot in order to check if we can
integrate it into the current Graffito repo ? I'm interesting to help you to
consolidate our works.
>
> From it, I developed 3 portlets:
>
> 1. CMS Tree Browser
> 2. CMS Document Viewer
> 3. CMS Search Portlet
>
> I need to decouple these from my specific implementation
> The coupling is very very low, they look for specific properties from
> document.getProperty such as hitrate on a search.
> Hope to contribute soon
>
> Also, saw that Christophe is writing similar portlets with Velocity
> I really prefer Velocity, so thats great
> My portlets used JSP because the tree view browser was integral, and I was
> working with Jeremy and he wrote the Jetspeed-2 tree browser so we went with
> that. Actuallly it looks very nice, and now supports lazy loading which i
> think is essential for browsing over large CMSs
Is it possible to port this treeview into the velocity world ?
The more I'm using Velocity, the more I like it. It is so simple compare to
jsp,jstl,jsf technologies.
As you will see, my browser provides another kind of navigation based on some
simple href like 'you are here : home>myfolder>anotherfolder>mydoc.
I think both kind of navigation are interesting.
>
> So thats my status
> Hope to start contributing by next week and can't wait to try out
> Christophe's new portlets
>
>
Maybe I can also resume what I'm doing :
* Mainly working on the Graffito Browser portlet :
* In the view mode :
- Simple navigation across the content tree.
-View document (HTML, simple text, binaries doc like word, images,
... ).
* In the edit mode :
- Manage folder (insert, update, delete)
- Manage documents (insert, update, delete). Kupu, an HTML editor
is integrated in this portlet. I prefer another HTML editor but there are some
licence issues.
- Upload documents
I think it is interesing to have all thoses features in one single portlet
but it provides a very large process action method. That's why I'm refactoring
to code to use some PortletActions. I will introduce this small feature next
week and If needed send the code to the J2 team (not yet commited).
I also build a Tab component for the velocity template based portlets. I
plan to submit the code to the J2 team when it will be used in the Graffito
portlets.
Plan to do :
* Add the GraffitoNews class in the Graffito model and RSS support.
* Add the permission management in the Browser portlet
* More integration with J2 :
* Graffito implementation for the page manager. I will need help for
this point.
* Define a Graffito Valve.
* Finalise the search service with a event handler service.
* Build a server management portlet (add, delete, update server references
and plugin).
* Webdav support
* JCR Support : I think we have to discuss on that topic ASAP.
* Workflow.
humm, we will be busy for a couple of month :-)
Christophe
