Maybe I'm not understanding what you propose in this message... but how is this
different from the current common practice?
-David
On Dec 22, 2009, at 1:47 AM, Abdullah Shaikh wrote:
> Hi All,
>
> When I was working on ecommerce I also found it difficult/troublesome to
> change the UI, so regarding having separation of UI / Code in the
> presentation layer, below are my thoughts, but I hadn't implemented them,
> because I needed to complete the project and had no time for this.
>
> What I feel is we can have all the data preparation in Groovy itself and
> just the displaying part in FTL page, this would reduce the complexity in
> FTL pages and would I guess provide the UI separation from code.
>
> For example, currently FTL pages are some what like this,
>
> if(this == that ) {
> <table>data goes here</table>
> } else {
> <table>data goes here</table>
> }
>
> What we can do is, put this logic in groovy and let the ftl display the
> data.
>
> Groovy :
> if(this == that) {
> context.put("data", data goes here);
> } else {
> context.put("data", other data goes here);
> }
>
> FTL :
>
> <table> data from context </table>
>
> This way the FTL pages will be free of any logic and will just render the
> data provided through context from Groovy.
>
> If using this technique,
>
> 1) Every FTL page will require a Groovy file for data preparation logic
> 2) Any changes can be does easily as Groovy won't require server restart
> 3) Changes in the UI can be done easily as we just need to paste the new UI
> code and get appropriate data from context and display it where ever you
> require.
>
> We can decide on a model for passing data to FTL pages, for example
>
> Groovy :
>
> data.put("userdetails", userdetails);
> data.put("paymentsinfo" paymentinfo);
> data.put"shoppingcart", shoppingcart);
> context.put("data", data);
>
> FTL :
>
> <table data.get("userdetails")</table>
> <table>data.get("paymentinfo", paymentinfo)</table>
> <table>data.get("shoppingcart" shoppintcart);
>
>
> This are just my thoughts on how can we separate UI from Code (display
> logic), I haven't seen or used Apache Wicket so no idea about how that will
> work or integrate in OFBiz.
>
> But this approach wont require any new integration or any POC as Groovy &
> FTL are already part of OFBiz.
>
> Let me know your thoughts or anything that I am missing.
>
> - Abdullah
>
> On Mon, Dec 21, 2009 at 11:06 PM, David E Jones <d...@me.com> wrote:
>
>>
>> On Dec 21, 2009, at 8:12 AM, Ean Schuessler wrote:
>>
>>> David E Jones wrote:
>>>> To sum up:
>>>>
>>>> 1. you want a full separation of concerns for the different roles in
>> your organization, something that won't require additional training beyond
>> their existing skill set
>>>>
>>>> 2. you want no dependencies between different roles so they can't mess
>> each other up or slow each other down
>>>>
>>>> 3. Apache Wicket will provide these things
>>>>
>>>> Does that sound about right?
>>>>
>>>> This sounds amazing! I can't wait to the see the results of an analysis
>> and comparison for each requirement, and a proof of concept and per-activity
>> comparison between the different approaches.
>>>>
>>> Just a touch Snarky there, Mr. Jones. :-)
>>
>> You're right, I was a bit snarky there. I apologize if I offended anyone. I
>> guess I should have said something like: That sounds a little bit too
>> amazing to be true.
>>
>>> Vasanth, I have spent some time examining Wicket and its not clear to me
>> that it is able to remove the problems in all but the most simple cases.
>> HTML for complicated multi-state widgets would still need to be divided into
>> many fragments, which are hard for the HTML designer to understand. It would
>> also still not be very clear to the designer where those fragments need to
>> be delineated because they do not understand the control flow.
>>>
>>> The deep set problem is that there will be many cases where you want to
>> look at a completed HTML assembly in its populated state to see how the
>> layout looks. That can only be done by editing on a live ofbiz environment
>> and that is always going to be pushing the skills of a GUI designer. What
>> using Wicket does achieve, however, is the elimination of a high level
>> widget system. While we are not really taking advantage of it it is possible
>> to have the OFBiz widgets present themselves in a Swing, SWT or GWT form
>> without rebuilding the entire GUI from scratch. That's a pretty big strike
>> against the Wicket approach. Wicket is also pretty tightly bound to Java the
>> language, which may or may not be the most productive thing to use depending
>> on your point of view (ie. PHP programmers are plentiful and cheap).
>>>
>>> In some problem domains like the shopping front-end we may need to accept
>> that the customer use-cases are simply to variable to make the widget
>> strategy add value. That's why, here at Brainfood, we've rebuilt the
>> e-commerce front end on our own templating system. Wicket might also be a
>> worthwhile strategy for that front end rebuild. I imagine that most of your
>> HTML workload revolves around that component. If you really believe in it, I
>> encourage you to build a Wicket version of the ecommerce component. I would
>> be happy to review it and compare its benefits with our effort.
>>
>> The general idea is an interesting one, ie of really separating things by
>> role and eliminating dependencies.
>>
>> I like the stuff you guys at Brainfood have done with WebSlinger, and it
>> certainly makes things easier for people in certain roles.
>>
>> In a way I wonder if points #1 and #2 that I listed above are actually
>> possible. My theory over the years is that they are simply not possible, and
>> all attempts are guaranteed to fall short because those requirements are not
>> "internally consistent". It would be interesting to have a well-funded R&D
>> project to get feedback from a bunch of people, assemble a number of
>> possible designs, then implement and test those designs in various
>> organizations. I'm not sure if that will ever happen, and I suppose even if
>> it did the winning design would probably be so biased by politicking that
>> the stated result might not be accurate.
>>
>> Anyway, it's a tough problem. The main issues I see are kind of like what
>> you listed Ean, namely:
>>
>> 1. different organizations have different roles and different skills sets,
>> so to be effective you'd really need to document a variety of organizations
>> and combinations of skill sets and be flexible enough to address at least a
>> few of the most common ones, or the ones that should be most easy for an
>> organization to assemble
>>
>> 2. it's not possible to completely eliminate dependencies between what
>> different people in different roles are doing; there might be some things
>> you could do to either mitigate (handle automatically or
>> transparently/implicitly) or obviate (fail fast/early) the problems, but
>> these dependencies are an inherent part of what is being built and IMO they
>> simply cannot be totally eliminated, especially if you want reusable parts
>> of the screens, etc
>>
>> My favorite approach so far to getting people to handle this well is to
>> divide front-end developers into those who are mostly visually talented, and
>> those who have gotten into scripting and such too. These people will have to
>> get used to working together in order to get things done, IMO. From time to
>> time you'll run into a person that is great at both, but not usually. Those
>> who are into scripting and working with straight HTML can usually get into
>> using the OFBiz widgets and FTL templates and do quite well with them (and
>> without very much training too). But that isn't everyone, and you certainly
>> need someone who can break things down and implement the technical things to
>> drive them.
>>
>> Some tools make this easier, and therefore require less technical
>> knowledge, but those tools typically also restrict what you can do. If you
>> want to keep it cheap and simple then that's great, just do what the tool
>> makes easy. If you really want to be able to design and build anything that
>> is "internally consistent" then you're going to need more flexible tools and
>> more knowledgeable people.
>>
>> Or am I wrong and the silver bullet solution does exist and I just haven't
>> yet had the pleasure of experiencing it?
>>
>> Hopefully this time I'm less snarky, without being too depressing... :)
>>
>> -David
>>
>>
>>
