Hi Nicolas "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. - Abdullah On Tue, Dec 22, 2009 at 2:04 PM, Nicolas Malin < [email protected]> wrote: > Hi Abdullah, > > It's a good Idea It's is possible to disable some calcul. > > 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. > > So +1 for your suggestion with warn on "big process" > > Nicolas > > Abdullah Shaikh a écrit : > > 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 <[email protected]> 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 >>> >>> >>> >>> >>> >> >> >> > > > -- > Nicolas MALIN > Consultant > Tél : 06.17.66.40.06 > Site projet : http://www.neogia.org/ > ------- > Société LibrenBerry > Tél : 02.48.02.56.12 > Site : http://www.librenberry.net/ > >
