On Sun, May 16, 2010 at 12:15 PM, Henry Saputra <[email protected]> wrote: > 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.
I see two issues with server side rendering : - Scalability, as usually you have to go to server for generating another piece of the ui... (e.g instead of requesting a new image and updating the ui to change the image being displayed, you need to submit and get a new ui rendered on the server) - Loose flexibility, as if I understand what you are proposing, data will be mashed together with the ui pieces during server rendering > 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. I'm not all familiar with Apache Click, but it seems that one issue with that is that it brings lots of different JS frameworks to the UI, and that might be an issue... but I don't want to jump to conclusions as I haven't had a chance to deeply investigate the project. > 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? > Well, I guess lots of us have provided different point of views here, but I don't want to discourage you so I was wondering if this is going to be a totally separate module that won't cause any disruption to current trunk, otherwise, if others members of the project are ok, I could setup a branch/sandbox for you to play with this. Thoughts ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
