Using Apache Wicket in Ofbiz presentation layer

[Vasanth Kamatgi]

Hello Ean,
That was a great metaphor that you used.  In fact, my inspiration to continue battling seemingly impossible tasks has been a car design & execution effort - Tata Nano - world's cheapest(!) car - http://www.counterjumper.com/2008/01/11/tata-nano-making-the-impossible-possible/.

Ean Schuessler wrote

David E Jones wrote:
> 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.
>  
Webslinger definitely makes certain things easier but it also destroys
the portability proposition of the widget system. We are currently
looking at supporting form widgets as a native document type in
webslinger, which may restore some of that portability.

One thing I have been curious about is building a XUL renderer, which
should be pretty thin.
> 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.
>  
Actually I think this is essentially going on and has for some time. I
think the difficulty of the problem is why there are so many "web
frameworks". There is no clear solution so people keep throwing things
up to see if they will stick.

I think the fundamental disconnect is analogous to automobile body
design -vs- powertrain design. On the one hand, you have people that
want to draw pictures of awesome looking cars and on the other hand you
have people who want to tackle physics problems to deliver power in a
system. Making those things blend together seamlessly, as you indicated,
requires an understanding of all the principals involved. Great
industrial design combines the intuition of art with the rigid demands
of engineering and you can't really get one or the other for free.
> 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?
>  
Even HTML is almost still too far into the engineering realm. The truly
beautiful tool is Photoshop, which makes the process of image creation
almost totally artistic and lets you forget that you are manipulating
data structures. In the free software world, Inkscape is actually quite
impressive in this way. You can totally forget that you are manipulating
SVG and simply draw. There is really no analog for this in the HTML
world, especially because of CSS.

In some ways, SquareSpace.com's online web design tool approaches what
I'd like to see a tool do, though it introduces many limitations. I'd
encourage everyone to look at its demo video. If we could provide a CMS
tool that acts like that and expose the power of the OFBiz business
logic into it, the world would be ours.
> Hopefully this time I'm less snarky, without being too depressing... :)
>  
A tough problem can be fun.

[hans_bakker]

On Tue, 2009-12-22 at 18:40 -0800, Vasanth Kamatgi wrote:
> .....
> But, I would see some merit in continuing
> the discussion to find the silver bullet for decoupling at rendering stage.
> :)

it is called proof of concept....?

--
Antwebsystems.com: Quality OFBiz services for competitive rates

[Vasanth Kamatgi]

Apologies if I have been rather insensitive to the your exogitation.  I was certainly not implying that we use Wicket.  I am neither an expert in Wicket nor a champion of Ofbiz.  I am merely elucidating the thoughts on the problems that I faced while having a whole team work on Ofbiz.  I like Ofbiz and am sold out on it.  I know that I have to work more, to convince the community of the change I am proposing and I am planning to do that in the next few weeks.  I am planning to follow the HEMP approach as suggested by David, starting next week and share with the community, what I arrive at.

Ean Schuessler wrote

Vasanth Kamatgi wrote:
> But, the downside of this approach is - I would be losing the ofbiz community
> improvements in the ecommerce front end.  for any change / bugfix /
> enhancement in the ecommerce module, I need to explicitly port it again in
> my own implementation, which is kind of contradictory to the reason why I
> had wanted to use an open source application with activity community in the
> first place.  In fact, we had evaluated this option as well but discarded it
> for the reason mentioned above.
>  
There is a risk but that risk is smaller than the community moving
arbitrarily to Wicket. If you feel that a Wicket solution would be so
strong that it would sway the opinion of the whole community then it is
your responsibility to undertake that risk. The community is very
unlikely to undertake such a risk based on someone saying "hey, I think
this is a great idea". We have undertaken a similar risk with our own
internal build-outs (worse, actually, since we built a new templating
framework instead of using an existing one).

Really, conducted properly, the risk you outline is not so high. In
theory, your Wicket solution will be a thin binding layer between the
core OFBiz logic (which won't need to change) and your customer's HTML
(which must be custom).

--
Ean Schuessler, CTO
[e-mail]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[Abdullah Shaikh]

Hi Ean,

Below is the modification of the example you have given as per what I
propose.

Groovy:
  def user =  dispatcher.runSync("getSpecialUser", [])
  context.userDetails = { user };

FTL:

<table>
   <#if(userDetails != null)>
        <tr>
              <td>
                  <span class="firstname">$user.firstName</span>
                  <span class="lastname">$user.lastName</span>
              </td>
          </tr>
    <else>
          <tr>
              <td>
                 <span class="notperson">User doesn't exists</span>
              </td>
          </tr>
        <#if>
</table>

- Abdullah

On Wed, Dec 23, 2009 at 2:24 AM, Ean Schuessler <[hidden email]> wrote:

> Abdullah Shaikh wrote:
>
>> "If your groovy compile some information, do findList, getRelated ... , if
>> you deploy for a customer a screen that don't use all information, you
>> generate unnecessary work to your database."
>>
>> But in groovy you will need to get only that data from database which will
>> be required for the FTL page
>>
>> It's like if an existing FTL gets "xyz" data from database, using this
>> approach it will be like, groovy get "xyz" data from the database and
>> putting it inside the context, FTL will get this data from the context.
>>
> If you use closures then the calls will only occur when they are used...
>
> Groovy:
>
> context.userDetails = {
>   def user =  dispatcher.runSync("getSpecialUser", [])
>   if (user.entityName == "Person") return """
>   <tr>
>       <td>
>           <span class="firstname">$user.firstName</span>
>           <span class="lastname">$user.lastName</span>
>            is definitely a person.
>       </td>
>   </tr>
> """ else return """
>   <tr>
>       <td>
>           <span class="notperson">User is not a person.</span>
>       </td>
>   </tr>
> """
> }
>
> FTL:
>
> <table>
> $userDetails.call()
> </table>
>
> This way the work of generating the user details is never done unless the
> FTL pulls them in. This approach is useful for all kinds of formatting
> chores.
>