Hi All, For rendering part, I think that if we want the webapp and google-app to be more than simple sample to show how to get the backend/services end points, we need to add UI framework to simplify extension and adding more features such as GSOC projects for search/tag, and OpenID. These modules (ie webapp and google-app) will use other endpoints to actually get the data or server side logic that allow developers to build his/her own UI on top of PhotArk superb services.
Even JSP is considered as server side technology what its actually do is to convert/compile the JSP file into servlet that handle the rendering in server side. When I said about server side rendering, I was proposing something like Apache Click that allows lightweight server side logic to allow easy templating for the html pages. The idea is to allow serving dynamic html instead of creating individual html pages. It will go to become unmanageable pretty quick. Updates to the page from calling back to PhotArk services could happen in client side. The initial rendering and flow could be done in server side. As Martin and others have mentioned we shouldnt cluttered server side logic with UI logic. These rendering mechanism should live in its own maven module, such as photark-ui module, so it wont interfere with middle and back logic. Getting back to separation of concerns, based on some prev ideas what about splitting photark as these modules: UI ----- This module should contain two major functionalities: -) rendering -> This should be photark UI framework for webapp and google-app. This part should generate dynamic html markups that could allow easy customization and extension as well as example on how to build client application to use photark. -) client side script/code -> This part contains javascript widgets and javascript code to send and process requests to/from photark services. This part should not depend on other client side framework. UI Services ------------------ These are SCA components that handle requests from client. These could be components that Luciano proposed before: Content Repository and GalleryAPI Data Access Layers and Core Services ------------------------------------------------------------ Provide abstraction for actual data for Gallery and Album. It could be File system, jcr, sdo, or other sources. This module also contain some bootstrap logic to select which composite file to launch (maybe as ContextListener) Based on the separation of concerns above PhotArk will expose these endpoints to users/developers: 1. Web application that fully render the UI to show full stack of PhotArk capabilities/features 2. client side library for manipulating contents and send request back to photark services. 3. Atom, REST and JSON-RPC endpoints to allow external developers to hit the server side functionalities directly. Thoughts? - Henry On Sun, May 16, 2010 at 8:51 AM, Martin Cooper <[email protected]> wrote: > 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. > > > >> 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, > > IMO, this is by far the most important piece, and it's crucial that we > get this right. Once we have the right service interface (and yes, I > prefer RESTful too), anyone can easily build an app on top of it, > regardless of technology. I should be able to build a DHTML app, as > our sample demonstrates, or use Flex or AIR or Silverlight or JavaFX > or whatever. I could perhaps even build a scripted app that doesn't > have or need a UI itself. But we have to keep these options in mind as > we design the service interface, and not "accidentally" nail it to > DHTML. > > > --------- 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) > > I'm not convinced about this, although I'm open to being persuaded. On > the plus side, it might help people build apps faster, but on the > minus side, its very existence means that we probably don't have the > optimal service interface. That suggests to me that we should focus on > getting the service interface right, instead of compensating for it > with another layer in the client. > > Also, if we do have such a layer, I believe it is important that it > _not_ rely on any other JavaScript framework. Doing that will > prejudice the experience towards whatever framework we choose, rather > than let the consumer choose their own. That is, if we choose to build > such a layer on top of Dojo, for instance, and I want to build my app > using ExtJS, now I have to choose between having 2 different > JavaScript frameworks in my app (bad) or having to re-implement the UI > API using something else (bad). > > A JavaScript UI API is also not useful for anyone using other > technologies such as Flex. > > > 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. > > I definitely agree with this being independent of the server side. > > > 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. > > I am with you on server-side rendering. In addition to the reasons you > mention, which I agree with, it also introduces another technology > boundary for someone who wants to customise the app; now they may need > to deal with Java and / or Java configuration in addition to DHTML or > their chosen client-side technology. > > -- > Martin Cooper > > > > Thoughts ? What do others think about this ? > > > > -- > > Luciano Resende > > http://people.apache.org/~lresende > > http://twitter.com/lresende1975 > > http://lresende.blogspot.com/ > > >
