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:
<#if(userDetails != null)>
$user.firstName
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 Ofbi
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
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 Sch
I agree with you in your observation that, this problem is difficult to
solve, and has factors weighing against a possible solution. So, I
understand the skepticism "if points #1 and #2 that I listed above are
actually possible".
I know that I am being very naive to say this, but I believe, ever
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 contrad
sfully employed?
>> 3) I am not aware, how to kick-off the analysis, requirement comparison,
>> POC
>> etc. activities. Guidance by community gurus would be a great help.
>>
>> Cheers,
>> Vasanth
>>
>> -Original Message-
>> From: David E Jones
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 requ
This is definitely the goal - it has some limitations, but that UI and usage is
downright awesome.
Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Dec 22, 2009, at 11:25 AM, Ean Schuessler wrote:
> In some ways, SquareSpace.com's online w
Abdullah Shaikh wrote:
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
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 c
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 re
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
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 w
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 fe
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 dep
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 slo
gt; etc. activities. Guidance by community gurus would be a great help.
>
> Cheers,
> Vasanth
>
> -Original Message-
> From: David E Jones [mailto:d...@me.com]
> Sent: Sunday, December 20, 2009 2:09 AM
> To: dev@ofbiz.apache.org
> Subject: Re: Using Apache Wicket in
On Dec 19, 2009, at 9:32 PM, Vasanth Kamatgi wrote:
> 3) I am not aware, how to kick-off the analysis, requirement comparison, POC
> etc. activities. Guidance by community gurus would be a great help.
This is what I use with clients to do requirements gathering, design, etc for
business applic
t: Re: Using Apache Wicket in Ofbiz presentation layer
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
t: Re: Using Apache Wicket in Ofbiz presentation layer
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
I had a quick look at wicket and this sounds pretty interesting for the
ecommerce component. Updating the ecommerce frontend UI is indeed
sometimes pretty cumbersome.
Looking forward to a proof of concept?
Regards,
Hans
On Sat, 2009-12-19 at 23:25 +0530, Vasanth Kamatgi wrote:
> Hi all,
>
>
>
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.
23 matches
Mail list logo
