GUIAPP in specialpurpose

[Jacques Le Roux]

Hi all,

What do you think about moving the
framework/guiapp
to
specialpurpose/guiapp

I see one advantage with this change : make closer guiapp and pos as for the moment guiapp is only used by POS. This will ease maintenance of POS...
One example : when commiting from specialpurpose branch we will see any changes in guiapp as well as in POS.

Thanks

Jacques

[David E Jones-2]

The guiapp component is _intentionally_ separated from the pos  
component because we may want to have other XUI/etc based gui apps at  
some point in the future...

Personally I'd like to see the separation cleaned up and increased,  
as opposed to reducing differences and separation.

-David


On Dec 5, 2006, at 9:36 AM, Jacques Le Roux wrote:

> Hi all,
>
> What do you think about moving the
> framework/guiapp
> to
> specialpurpose/guiapp
>
> I see one advantage with this change : make closer guiapp and pos  
> as for the moment guiapp is only used by POS. This will ease  
> maintenance of POS...
> One example : when commiting from specialpurpose branch we will see  
> any changes in guiapp as well as in POS.
>
> Thanks
>
> Jacques

[Jacques Le Roux]

OK, I see what you mean. I have created a Jira issue for that :
"Harcoded string to POS startupFile in GUIAPP component" https://issues.apache.org/jira/browse/OFBIZ-471

Jacques

From: "David E Jones" <[hidden email]>

>
> The guiapp component is _intentionally_ separated from the pos  
> component because we may want to have other XUI/etc based gui apps at  
> some point in the future...
>
> Personally I'd like to see the separation cleaned up and increased,  
> as opposed to reducing differences and separation.
>
> -David
>
>
> On Dec 5, 2006, at 9:36 AM, Jacques Le Roux wrote:
>
> > Hi all,
> >
> > What do you think about moving the
> > framework/guiapp
> > to
> > specialpurpose/guiapp
> >
> > I see one advantage with this change : make closer guiapp and pos  
> > as for the moment guiapp is only used by POS. This will ease  
> > maintenance of POS...
> > One example : when commiting from specialpurpose branch we will see  
> > any changes in guiapp as well as in POS.
> >
> > Thanks
> >
> > Jacques

[Chandresh Turakhia]

 Nice to have another director gui and have sub folders like
XUI
XAL
etc

Same can be done for HttpContainers like catalina, jetty, geronimo

Just a thought. But honestly needing help to have XAL container

Chand
----- Original Message -----
From: "David E Jones" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, December 05, 2006 10:07 AM
Subject: Re: GUIAPP in specialpurpose

>
> The guiapp component is _intentionally_ separated from the pos  
> component because we may want to have other XUI/etc based gui apps at  
> some point in the future...
>
> Personally I'd like to see the separation cleaned up and increased,  
> as opposed to reducing differences and separation.
>
> -David
>
>
> On Dec 5, 2006, at 9:36 AM, Jacques Le Roux wrote:
>
>> Hi all,
>>
>> What do you think about moving the
>> framework/guiapp
>> to
>> specialpurpose/guiapp
>>
>> I see one advantage with this change : make closer guiapp and pos  
>> as for the moment guiapp is only used by POS. This will ease  
>> maintenance of POS...
>> One example : when commiting from specialpurpose branch we will see  
>> any changes in guiapp as well as in POS.
>>
>> Thanks
>>
>> Jacques
>
>

[Ean Schuessler]

On Tuesday 05 December 2006 22:59, Chandresh Turakhia wrote:
>  Nice to have another director gui and have sub folders like
> XUI
> XAL
> etc

Dojo.

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

[cjhowe]

I've only kicked the tires with using Dojo in OFBiz,
but I don't believe there is anything "special" needed
to utilize the dojo toolkit outside of including the
js file.  See Jira Issue OFBIZ-441 for a simple
approach.

The only possible benefit would perhaps be perhaps an
example app.

What other "stuff" were you thinking for this?
--- Ean Schuessler <[hidden email]> wrote:

> On Tuesday 05 December 2006 22:59, Chandresh
> Turakhia wrote:
> >  Nice to have another director gui and have sub
> folders like
> > XUI
> > XAL
> > etc
>
> Dojo.
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>

[Ean Schuessler]

On Monday 11 December 2006 12:39, Chris Howe wrote:

> I've only kicked the tires with using Dojo in OFBiz,
> but I don't believe there is anything "special" needed
> to utilize the dojo toolkit outside of including the
> js file.  See Jira Issue OFBIZ-441 for a simple
> approach.
>
> The only possible benefit would perhaps be perhaps an
> example app.
>
> What other "stuff" were you thinking for this?

It would be pretty insane if you could bind Dojo events to SECA/ECAs on the
server side so that widgets would automagically update their values. In fact,
anything that would keep you from having to build servlet pages that extract
values, spit javascript, etc. would be good. Being able to call the
dispatcher from the client side and get results would be cool. Binding
services to widgets in Dojo would be cool too.

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

[Anil Patel]

We can do this with Yahoo Ajax toolkit. It ties into ofbiz web controller.



On 12/11/06, Ean Schuessler <[hidden email]> wrote:

>
> On Monday 11 December 2006 12:39, Chris Howe wrote:
> > I've only kicked the tires with using Dojo in OFBiz,
> > but I don't believe there is anything "special" needed
> > to utilize the dojo toolkit outside of including the
> > js file.  See Jira Issue OFBIZ-441 for a simple
> > approach.
> >
> > The only possible benefit would perhaps be perhaps an
> > example app.
> >
> > What other "stuff" were you thinking for this?
>
> It would be pretty insane if you could bind Dojo events to SECA/ECAs on
> the
> server side so that widgets would automagically update their values. In
> fact,
> anything that would keep you from having to build servlet pages that
> extract
> values, spit javascript, etc. would be good. Being able to call the
> dispatcher from the client side and get results would be cool. Binding
> services to widgets in Dojo would be cool too.
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>

[Tim Ruppert]

We've got things going on with Yahoo, JSON and google web toolkit at  
the moment.  Once we've got more of this figured out as to the pros  
and cons - we'll send it along.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6594


On Dec 11, 2006, at 11:57 AM, Anil Patel wrote:

> We can do this with Yahoo Ajax toolkit. It ties into ofbiz web  
> controller.
>
>
>
> On 12/11/06, Ean Schuessler <[hidden email]> wrote:
>>
>> On Monday 11 December 2006 12:39, Chris Howe wrote:
>> > I've only kicked the tires with using Dojo in OFBiz,
>> > but I don't believe there is anything "special" needed
>> > to utilize the dojo toolkit outside of including the
>> > js file.  See Jira Issue OFBIZ-441 for a simple
>> > approach.
>> >
>> > The only possible benefit would perhaps be perhaps an
>> > example app.
>> >
>> > What other "stuff" were you thinking for this?
>>
>> It would be pretty insane if you could bind Dojo events to SECA/
>> ECAs on
>> the
>> server side so that widgets would automagically update their  
>> values. In
>> fact,
>> anything that would keep you from having to build servlet pages that
>> extract
>> values, spit javascript, etc. would be good. Being able to call the
>> dispatcher from the client side and get results would be cool.  
>> Binding
>> services to widgets in Dojo would be cool too.
>>
>> --
>> Ean Schuessler, CTO
>> [hidden email]
>> 214-720-0700 x 315
>> Brainfood, Inc.
>> http://www.brainfood.com
>>