Hi Luciano, Long emails always welcomed =)
My comments inline: On Sat, May 15, 2010 at 9:54 PM, Luciano Resende <[email protected]>wrote: > Let me start for apologizing for the long e-mail :) > > On Sat, May 15, 2010 at 8:09 PM, Henry Saputra <[email protected]> > wrote: > > Hi All, > > > > Currently PhotArk web application (webapp) and google-app modules use > just > > html files for UI and relying on Javascript for sending request back to > > PhotArk components and updating the markup on json callback. > > This design is hard to maintain and extend to add more features > > and customization. > > > What are the main issues you are having here ? Can you describe your > pain points ? I do believe our current design has grown in the wrong > direction, and instead of providing a facade service that return > business objects to the client, we have created multiple operations to > return specific information. I want to start fixing that using > PHOTARK-42. > > Not so much about pain points =) I just thought what would be the purpose of the photark web app and the google-app modules? Will they be just samples on how write web client to call photark SCA end points or they will be more like base modules that developers could extend/modify to suit their look and feel requirements. > If its ok with everyone I would like to start discussion about direction > to > > improve the UI design/framework to allow customization and easy > development > > to add more features. > > > > +1, we definitely need a easy way to allow users that are using the > sample UI we provide and customize it, but see below for some thoughts > on design direction. > > > Here are some ideas to get the discussion rolling: > > > > 1. Add PhotArkRenderingServlet component to generate the markup for both > > webapp and google-app. The servlet will have PhotArkHtmlRenderer class to > > render html markups but not limited to it. > > External developers could replace this renderer with his own or extend > > the PhotArkHtmlRenderer to override some methods for custom behaviors. > > The advantage with this approach is that we control the rendering process > > which allows us to customize for PhotArk efficiency and performance. > > The downside is we control the rendering process (^_^) so we have to add > > some foundation code to make it work. > > > > 2. Use existing lightweight web framework that supports templating like > > Apache Click (http://click.apache.org/). This will allow reuse of html > pages > > for easy maintenance. > > The advantage with this approach is that we have most boilerplate codes > > being taking care of by the web framework. Just need to our own custom > code > > for PhotArk UI. > > The downside is we add dependency on another project and add learning > curve > > to developers when trying to adopt PhotArk. > > > > > I believe that the most flexible way is to apply separation of > concerns and have different layes for the project : > > Content Repository - an abstraction layer to interact with the photo > storage, we are currently focusing on JCR as the main repository, but > I believe we can have that to be easily replaced with simple > FileSystem or something for Google AppEngine. > > Gallery API - A layer that will allow client applications to interact > with the content repository. The client can be web browser or other > different remote client that has a need to integrate with the photo > content repository. As for this layer, we should fixup the current > implementation and make the client/server conversation more atomic > passing business objects instead of using a call to retrieve specific > information. In the future, we can think about a more pure REST > approach for this API, and I'm finalizing a REST binding in Tuscany > that would help us accomplish this second phase, > > I think this is what you were after with PHOTARK-42 jira? +1 using the REST API for this. --------- Separation layer from server > > UI API - This is something I've been thinking, but I don't have > nothing concrete on it yet. The idea was to provide a JS Client API > that would allow to simplify the creation of different UI (web pages) > > UI - This is the presentation layer, and I believe it should be > independent of the server side to allow other websites and different > clients to easily integrate with the project. Customization of the > sample ui we provide should be done on this layer, and I was thinking > if we could use something similar to what blogger use and allow some > type of templating that would be handled on the JS side. Looks like > there is already some support for this in dojo. > > If we move to have UI rendering on the server side, I think we will > loose a lot of flexibility, and will most likely add some complexity > for UI Developers trying to just consume some of PhotArk content to > integrate in their website/mashup. > > Thoughts ? What do others think about this ? > Separation of layers are always good =) +1 to have UI API, maybe we could add Javascript library to wrap dojo calls? I think by moving the rendering task to the server (via servlet or web framework) add flexibility for external developers if we want to make the webapp and google app modules as "production" ready. Meaning that developers could extend or replace our default look and feel by extending or replacing template files and styles to achieve the desired UI. For UI Developers that simply want to consume PhotArk content we could ask them to use the UI API to get the data. Just my 2 cents. - Henry > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/ >
