incubator-photark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <>
Subject Re: [PhotArk UI] Discussion for PhotArk UI framework direction
Date Sun, 16 May 2010 15:51:03 GMT
On Sat, May 15, 2010 at 9:54 PM, Luciano Resende <> wrote:
> Let me start for apologizing for the long e-mail :)
> On Sat, May 15, 2010 at 8:09 PM, Henry Saputra <> 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
>> 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 ( 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

> --------- 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

View raw message