Dev - Proposal for Ajax enhanced OFbiz
Locked
12
12
 
|
It's great to get all this feedback.
The reason I proposed that we should have a component for ajax- related work in OFBiz is so that it becomes a central point for collaboration on it. Of course, one of the first steps would be to find out what other developers have done and identify the right framework(s). Once we do have those discussions, though, it would be nice to have a place to put things so people could start experimenting with it and see it in action. By having a repository for it, that becomes possible, and I think that's very important to make ajax actionable in OFBiz, rather than just a point of discussion. That's why I'm proposing a repository component for it first. The reasons I thought that it should be a separate component versus the webapp are: 1. It is, as David says, different in that it's mostly client side libraries with maybe a few servlet methods, so there's not too much overlap between the two. Over time different people might get involved with it than with the OFBiz webapp framework. 2. If it's a separate component, it might be easier for people who are using different versions of OFBiz to pull it into whatever version they're working with. 3. Also, since it's mostly client-side stuff, it'd require a <webapp > defined in its ofbiz-component.xml. I wasn't sure whether it was a good idea to have a <webapp> defined inside of the webapp/ component. So that's my 2 cents. Si On Jun 14, 2006, at 2:09 AM, Andrew Sykes wrote: > Jacques, > >> Why ? Mmm are you serious ? > > Heh, I thought I might get a response like that :-) > > It seems that to take advantage of any Ajax stuff properly, it would > require adding stuff to the Form Widgets e.g. <input > ajax="autocomplete" />, So I got to thinking perhaps JS could actually > render these, no reason why not! - Apart from all the work involved! > > It's not a well formed idea, I was just hoping that if I mentioned it, > someone would either see the value of it, or tell me to shut up! > -- > Kind Regards > Andrew Sykes <[hidden email]> > Sykes Development Ltd > http://www.sykesdevelopment.com > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
Si,
Is there really that much to it, that it needs its own component? I guess you'd have a .css, a .js and a few services mounted to "service" the js calls. What else would there be? Couldn't this just go in /images ? Like David says, AJAX is just a currently popular label for a bunch of older technologies, all of which are used in some form already. I'm not trying to diminish the effort involved in making this work nicely, because I believe it's far from trivial, but I can't visualise a need for a separate component... Also, I think it's important to figure out what we want out of an AJAX framework, I can't see how a valid selection can be made without predefined criteria. What do you think? - Andrew On Wed, 2006-06-14 at 08:55 -0700, Si Chen wrote: > It's great to get all this feedback. > > The reason I proposed that we should have a component for ajax- > related work in OFBiz is so that it becomes a central point for > collaboration on it. Of course, one of the first steps would be to > find out what other developers have done and identify the right > framework(s). Once we do have those discussions, though, it would be > nice to have a place to put things so people could start > experimenting with it and see it in action. By having a repository > for it, that becomes possible, and I think that's very important to > make ajax actionable in OFBiz, rather than just a point of > discussion. That's why I'm proposing a repository component for it > first. > > The reasons I thought that it should be a separate component versus > the webapp are: > 1. It is, as David says, different in that it's mostly client side > libraries with maybe a few servlet methods, so there's not too much > overlap between the two. Over time different people might get > involved with it than with the OFBiz webapp framework. > 2. If it's a separate component, it might be easier for people who > are using different versions of OFBiz to pull it into whatever > version they're working with. > 3. Also, since it's mostly client-side stuff, it'd require a <webapp > > defined in its ofbiz-component.xml. I wasn't sure whether it was > a good idea to have a <webapp> defined inside of the webapp/ component. > > So that's my 2 cents. > > Si > > > On Jun 14, 2006, at 2:09 AM, Andrew Sykes wrote: > > > Jacques, > > > >> Why ? Mmm are you serious ? > > > > Heh, I thought I might get a response like that :-) > > > > It seems that to take advantage of any Ajax stuff properly, it would > > require adding stuff to the Form Widgets e.g. <input > > ajax="autocomplete" />, So I got to thinking perhaps JS could actually > > render these, no reason why not! - Apart from all the work involved! > > > > It's not a well formed idea, I was just hoping that if I mentioned it, > > someone would either see the value of it, or tell me to shut up! > > -- > > Kind Regards > > Andrew Sykes <[hidden email]> > > Sykes Development Ltd > > http://www.sykesdevelopment.com > > > > > > _______________________________________________ > > Dev mailing list > > [hidden email] > > http://lists.ofbiz.org/mailman/listinfo/dev > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
In reply to this post by Si Chen-2
For what I understand, we are trying to implement (or integrate) some
shared Ajax components that can be used to facilitate the usage of Ajax widgets in OFBiz's screens. When these common components will be ready we could move them somewhere in the framework area (in the "webapp" component or into a new "ajax" component). However I think that, before we can create and consolidate such components we will need to try to put some Ajax code into some of the existing screens. For example, we could try to improve some of the lookup screens, or the bom tree representation :-), and so we will also need something experimental under the 'application' area. Since I don't think that having too much experimental code into the framework and application areas is a good idea, what about going back to the Si's initial proposal? I.e adding one experimental component under the specialized folder: the component will extend some of the standard OFbiz screens (adding to them the Ajax code) and all the external ajax libraries needed to run them. When everything will be good enough we could move the libraries to the framework and the ajax screens to the relevant applications (order, manufacturing etc...). Does it make sense? Jacopo Si Chen wrote: > It's great to get all this feedback. > > The reason I proposed that we should have a component for ajax- > related work in OFBiz is so that it becomes a central point for > collaboration on it. Of course, one of the first steps would be to > find out what other developers have done and identify the right > framework(s). Once we do have those discussions, though, it would be > nice to have a place to put things so people could start > experimenting with it and see it in action. By having a repository > for it, that becomes possible, and I think that's very important to > make ajax actionable in OFBiz, rather than just a point of > discussion. That's why I'm proposing a repository component for it > first. > > The reasons I thought that it should be a separate component versus > the webapp are: > 1. It is, as David says, different in that it's mostly client side > libraries with maybe a few servlet methods, so there's not too much > overlap between the two. Over time different people might get > involved with it than with the OFBiz webapp framework. > 2. If it's a separate component, it might be easier for people who > are using different versions of OFBiz to pull it into whatever > version they're working with. > 3. Also, since it's mostly client-side stuff, it'd require a <webapp > > defined in its ofbiz-component.xml. I wasn't sure whether it was > a good idea to have a <webapp> defined inside of the webapp/ component. > > So that's my 2 cents. > > Si > > > On Jun 14, 2006, at 2:09 AM, Andrew Sykes wrote: > >> Jacques, >> >>> Why ? Mmm are you serious ? >> Heh, I thought I might get a response like that :-) >> >> It seems that to take advantage of any Ajax stuff properly, it would >> require adding stuff to the Form Widgets e.g. <input >> ajax="autocomplete" />, So I got to thinking perhaps JS could actually >> render these, no reason why not! - Apart from all the work involved! >> >> It's not a well formed idea, I was just hoping that if I mentioned it, >> someone would either see the value of it, or tell me to shut up! >> -- >> Kind Regards >> Andrew Sykes <[hidden email]> >> Sykes Development Ltd >> http://www.sykesdevelopment.com >> >> >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
In reply to this post by Andrew Sykes
What if we need to import a few existing ajax libraries? And have
different servlet methods for different types of lookups (ie, partyId from last name, productId from description or brand name, etc. etc.)? As to what we want out of an ajax framework, we can discuss that over time--but it'll really be driven the way the rest of the project is, based on what the contributors want or can code. Si On Jun 14, 2006, at 9:15 AM, Andrew Sykes wrote: > Si, > > Is there really that much to it, that it needs its own component? > > I guess you'd have a .css, a .js and a few services mounted to > "service" > the js calls. > > What else would there be? > > Couldn't this just go in /images ? > > Like David says, AJAX is just a currently popular label for a bunch of > older technologies, all of which are used in some form already. > > I'm not trying to diminish the effort involved in making this work > nicely, because I believe it's far from trivial, but I can't > visualise a > need for a separate component... > > Also, I think it's important to figure out what we want out of an AJAX > framework, I can't see how a valid selection can be made without > predefined criteria. > > What do you think? > - Andrew > > On Wed, 2006-06-14 at 08:55 -0700, Si Chen wrote: >> It's great to get all this feedback. >> >> The reason I proposed that we should have a component for ajax- >> related work in OFBiz is so that it becomes a central point for >> collaboration on it. Of course, one of the first steps would be to >> find out what other developers have done and identify the right >> framework(s). Once we do have those discussions, though, it would be >> nice to have a place to put things so people could start >> experimenting with it and see it in action. By having a repository >> for it, that becomes possible, and I think that's very important to >> make ajax actionable in OFBiz, rather than just a point of >> discussion. That's why I'm proposing a repository component for it >> first. >> >> The reasons I thought that it should be a separate component versus >> the webapp are: >> 1. It is, as David says, different in that it's mostly client side >> libraries with maybe a few servlet methods, so there's not too much >> overlap between the two. Over time different people might get >> involved with it than with the OFBiz webapp framework. >> 2. If it's a separate component, it might be easier for people who >> are using different versions of OFBiz to pull it into whatever >> version they're working with. >> 3. Also, since it's mostly client-side stuff, it'd require a <webapp >>> defined in its ofbiz-component.xml. I wasn't sure whether it was >> a good idea to have a <webapp> defined inside of the webapp/ >> component. >> >> So that's my 2 cents. >> >> Si >> >> >> On Jun 14, 2006, at 2:09 AM, Andrew Sykes wrote: >> >>> Jacques, >>> >>>> Why ? Mmm are you serious ? >>> >>> Heh, I thought I might get a response like that :-) >>> >>> It seems that to take advantage of any Ajax stuff properly, it would >>> require adding stuff to the Form Widgets e.g. <input >>> ajax="autocomplete" />, So I got to thinking perhaps JS could >>> actually >>> render these, no reason why not! - Apart from all the work involved! >>> >>> It's not a well formed idea, I was just hoping that if I >>> mentioned it, >>> someone would either see the value of it, or tell me to shut up! >>> -- >>> Kind Regards >>> Andrew Sykes <[hidden email]> >>> Sykes Development Ltd >>> http://www.sykesdevelopment.com >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/dev >> >> >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev > -- > Kind Regards > Andrew Sykes <[hidden email]> > Sykes Development Ltd > http://www.sykesdevelopment.com > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
In reply to this post by Andrew Sykes
> Like David says, AJAX is just a currently popular label for a bunch of
> older technologies, all of which are used in some form already. Yes and no... I was kind of skeptical myself, but there is some really fancy javascript stuff coming out these days. It's probably less appropriate for a site's front end unless you also take the time to degrade carefully for people who don't have it, but in the backend of the site, there is the potential to speed things up, and add some nice effects. Also, the better libraries are nice because the people who know all the insidious tricks of making JS work in a cross platform way have already done so and packaged it up into a library. It's necessary to be careful not to go overboard, of course! Here's a fun, if simplistic example: http://demo.script.aculo.us/shop (Check out the clean, simple ruby on rails source code too:-) -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/ _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
|
|
In reply to this post by Jacopo Cappellato
I'm fine with it in the specialized/ folder too, but like anything
else, it'll get better with use. My idea was basically to have the tools in place so people can start working on other screens with it. On Jun 14, 2006, at 9:17 AM, Jacopo Cappellato wrote: > For what I understand, we are trying to implement (or integrate) some > shared Ajax components that can be used to facilitate the usage of > Ajax > widgets in OFBiz's screens. > When these common components will be ready we could move them > somewhere > in the framework area (in the "webapp" component or into a new "ajax" > component). > However I think that, before we can create and consolidate such > components we will need to try to put some Ajax code into some of the > existing screens. > For example, we could try to improve some of the lookup screens, or > the > bom tree representation :-), and so we will also need something > experimental under the 'application' area. > Since I don't think that having too much experimental code into the > framework and application areas is a good idea, what about going > back to > the Si's initial proposal? I.e adding one experimental component under > the specialized folder: the component will extend some of the standard > OFbiz screens (adding to them the Ajax code) and all the external ajax > libraries needed to run them. > When everything will be good enough we could move the libraries to the > framework and the ajax screens to the relevant applications (order, > manufacturing etc...). > > Does it make sense? > > Jacopo > > Si Chen wrote: >> It's great to get all this feedback. >> >> The reason I proposed that we should have a component for ajax- >> related work in OFBiz is so that it becomes a central point for >> collaboration on it. Of course, one of the first steps would be to >> find out what other developers have done and identify the right >> framework(s). Once we do have those discussions, though, it would be >> nice to have a place to put things so people could start >> experimenting with it and see it in action. By having a repository >> for it, that becomes possible, and I think that's very important to >> make ajax actionable in OFBiz, rather than just a point of >> discussion. That's why I'm proposing a repository component for it >> first. >> >> The reasons I thought that it should be a separate component versus >> the webapp are: >> 1. It is, as David says, different in that it's mostly client side >> libraries with maybe a few servlet methods, so there's not too much >> overlap between the two. Over time different people might get >> involved with it than with the OFBiz webapp framework. >> 2. If it's a separate component, it might be easier for people who >> are using different versions of OFBiz to pull it into whatever >> version they're working with. >> 3. Also, since it's mostly client-side stuff, it'd require a <webapp >>> defined in its ofbiz-component.xml. I wasn't sure whether it was >> a good idea to have a <webapp> defined inside of the webapp/ >> component. >> >> So that's my 2 cents. >> >> Si >> >> >> On Jun 14, 2006, at 2:09 AM, Andrew Sykes wrote: >> >>> Jacques, >>> >>>> Why ? Mmm are you serious ? >>> Heh, I thought I might get a response like that :-) >>> >>> It seems that to take advantage of any Ajax stuff properly, it would >>> require adding stuff to the Form Widgets e.g. <input >>> ajax="autocomplete" />, So I got to thinking perhaps JS could >>> actually >>> render these, no reason why not! - Apart from all the work involved! >>> >>> It's not a well formed idea, I was just hoping that if I >>> mentioned it, >>> someone would either see the value of it, or tell me to shut up! >>> -- >>> Kind Regards >>> Andrew Sykes <[hidden email]> >>> Sykes Development Ltd >>> http://www.sykesdevelopment.com >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/dev >> >> >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev >> > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
In reply to this post by Si Chen-2
Hi Si,
Si Chen wrote: > What if we need to import a few existing ajax libraries? If we will create an experimental component in the specialized folder (or in some other public svn server, the real important thing, in my opinion, is that it should be one OFBiz component that can be dropped into the hot-deploy folder) we could put all the libraries in it. > And have > different servlet methods for different types of lookups (ie, partyId > from last name, productId from description or brand name, etc. etc.)? > Many of these service could go into the party, product etc... because they are not Ajax specific... Jacopo > As to what we want out of an ajax framework, we can discuss that over > time--but it'll really be driven the way the rest of the project is, > based on what the contributors want or can code. > > Si > > On Jun 14, 2006, at 9:15 AM, Andrew Sykes wrote: > >> Si, >> >> Is there really that much to it, that it needs its own component? >> >> I guess you'd have a .css, a .js and a few services mounted to >> "service" >> the js calls. >> >> What else would there be? >> >> Couldn't this just go in /images ? >> >> Like David says, AJAX is just a currently popular label for a bunch of >> older technologies, all of which are used in some form already. >> >> I'm not trying to diminish the effort involved in making this work >> nicely, because I believe it's far from trivial, but I can't >> visualise a >> need for a separate component... >> >> Also, I think it's important to figure out what we want out of an AJAX >> framework, I can't see how a valid selection can be made without >> predefined criteria. >> >> What do you think? >> - Andrew >> >> On Wed, 2006-06-14 at 08:55 -0700, Si Chen wrote: >>> It's great to get all this feedback. >>> >>> The reason I proposed that we should have a component for ajax- >>> related work in OFBiz is so that it becomes a central point for >>> collaboration on it. Of course, one of the first steps would be to >>> find out what other developers have done and identify the right >>> framework(s). Once we do have those discussions, though, it would be >>> nice to have a place to put things so people could start >>> experimenting with it and see it in action. By having a repository >>> for it, that becomes possible, and I think that's very important to >>> make ajax actionable in OFBiz, rather than just a point of >>> discussion. That's why I'm proposing a repository component for it >>> first. >>> >>> The reasons I thought that it should be a separate component versus >>> the webapp are: >>> 1. It is, as David says, different in that it's mostly client side >>> libraries with maybe a few servlet methods, so there's not too much >>> overlap between the two. Over time different people might get >>> involved with it than with the OFBiz webapp framework. >>> 2. If it's a separate component, it might be easier for people who >>> are using different versions of OFBiz to pull it into whatever >>> version they're working with. >>> 3. Also, since it's mostly client-side stuff, it'd require a <webapp >>>> defined in its ofbiz-component.xml. I wasn't sure whether it was >>> a good idea to have a <webapp> defined inside of the webapp/ >>> component. >>> >>> So that's my 2 cents. >>> >>> Si >>> >>> >>> On Jun 14, 2006, at 2:09 AM, Andrew Sykes wrote: >>> >>>> Jacques, >>>> >>>>> Why ? Mmm are you serious ? >>>> Heh, I thought I might get a response like that :-) >>>> >>>> It seems that to take advantage of any Ajax stuff properly, it would >>>> require adding stuff to the Form Widgets e.g. <input >>>> ajax="autocomplete" />, So I got to thinking perhaps JS could >>>> actually >>>> render these, no reason why not! - Apart from all the work involved! >>>> >>>> It's not a well formed idea, I was just hoping that if I >>>> mentioned it, >>>> someone would either see the value of it, or tell me to shut up! >>>> -- >>>> Kind Regards >>>> Andrew Sykes <[hidden email]> >>>> Sykes Development Ltd >>>> http://www.sykesdevelopment.com >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [hidden email] >>>> http://lists.ofbiz.org/mailman/listinfo/dev >>> >>> _______________________________________________ >>> Dev mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/dev >> -- >> Kind Regards >> Andrew Sykes <[hidden email]> >> Sykes Development Ltd >> http://www.sykesdevelopment.com >> >> >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
In reply to this post by Si Chen-2
Si,
On Wed, 2006-06-14 at 09:21 -0700, Si Chen wrote: > As to what we want out of an ajax framework, we can discuss that > over > time--but it'll really be driven the way the rest of the project is, > based on what the contributors want or can code. I guess that's what I'm asking, what do the contributors want? Without that you might choose the wrong js libraries etc... -- Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
In reply to this post by Si Chen-2
Yeah, I still don't like the specialized folder idea. 1. it's too easy for it to go in a direction that will be difficult to use in the future 2. we _never_ want anything in the application or framework components to depend (out of the box) on anything int he specialized components 3. as was mentioned chances are it won't get nearly as much attention in a specialized component -David Si Chen wrote: > I'm fine with it in the specialized/ folder too, but like anything > else, it'll get better with use. > > My idea was basically to have the tools in place so people can start > working on other screens with it. > > On Jun 14, 2006, at 9:17 AM, Jacopo Cappellato wrote: > >> For what I understand, we are trying to implement (or integrate) some >> shared Ajax components that can be used to facilitate the usage of >> Ajax >> widgets in OFBiz's screens. >> When these common components will be ready we could move them >> somewhere >> in the framework area (in the "webapp" component or into a new "ajax" >> component). >> However I think that, before we can create and consolidate such >> components we will need to try to put some Ajax code into some of the >> existing screens. >> For example, we could try to improve some of the lookup screens, or >> the >> bom tree representation :-), and so we will also need something >> experimental under the 'application' area. >> Since I don't think that having too much experimental code into the >> framework and application areas is a good idea, what about going >> back to >> the Si's initial proposal? I.e adding one experimental component under >> the specialized folder: the component will extend some of the standard >> OFbiz screens (adding to them the Ajax code) and all the external ajax >> libraries needed to run them. >> When everything will be good enough we could move the libraries to the >> framework and the ajax screens to the relevant applications (order, >> manufacturing etc...). >> >> Does it make sense? >> >> Jacopo >> >> Si Chen wrote: >>> It's great to get all this feedback. >>> >>> The reason I proposed that we should have a component for ajax- >>> related work in OFBiz is so that it becomes a central point for >>> collaboration on it. Of course, one of the first steps would be to >>> find out what other developers have done and identify the right >>> framework(s). Once we do have those discussions, though, it would be >>> nice to have a place to put things so people could start >>> experimenting with it and see it in action. By having a repository >>> for it, that becomes possible, and I think that's very important to >>> make ajax actionable in OFBiz, rather than just a point of >>> discussion. That's why I'm proposing a repository component for it >>> first. >>> >>> The reasons I thought that it should be a separate component versus >>> the webapp are: >>> 1. It is, as David says, different in that it's mostly client side >>> libraries with maybe a few servlet methods, so there's not too much >>> overlap between the two. Over time different people might get >>> involved with it than with the OFBiz webapp framework. >>> 2. If it's a separate component, it might be easier for people who >>> are using different versions of OFBiz to pull it into whatever >>> version they're working with. >>> 3. Also, since it's mostly client-side stuff, it'd require a <webapp >>>> defined in its ofbiz-component.xml. I wasn't sure whether it was >>> a good idea to have a <webapp> defined inside of the webapp/ >>> component. >>> >>> So that's my 2 cents. >>> >>> Si >>> >>> >>> On Jun 14, 2006, at 2:09 AM, Andrew Sykes wrote: >>> >>>> Jacques, >>>> >>>>> Why ? Mmm are you serious ? >>>> Heh, I thought I might get a response like that :-) >>>> >>>> It seems that to take advantage of any Ajax stuff properly, it would >>>> require adding stuff to the Form Widgets e.g. <input >>>> ajax="autocomplete" />, So I got to thinking perhaps JS could >>>> actually >>>> render these, no reason why not! - Apart from all the work involved! >>>> >>>> It's not a well formed idea, I was just hoping that if I >>>> mentioned it, >>>> someone would either see the value of it, or tell me to shut up! >>>> -- >>>> Kind Regards >>>> Andrew Sykes <[hidden email]> >>>> Sykes Development Ltd >>>> http://www.sykesdevelopment.com >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [hidden email] >>>> http://lists.ofbiz.org/mailman/listinfo/dev >>> >>> _______________________________________________ >>> Dev mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/dev >>> >> >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
In reply to this post by Si Chen-2
Si Chen wrote: > It's great to get all this feedback. > > The reason I proposed that we should have a component for ajax- > related work in OFBiz is so that it becomes a central point for > collaboration on it. Of course, one of the first steps would be to > find out what other developers have done and identify the right > framework(s). Once we do have those discussions, though, it would be > nice to have a place to put things so people could start > experimenting with it and see it in action. By having a repository > for it, that becomes possible, and I think that's very important to > make ajax actionable in OFBiz, rather than just a point of > discussion. That's why I'm proposing a repository component for it > first. There is _no_ reason I can see that this is not actionable right now. We don't need a special component for it, or even commit access. So far we've spent all of this time talking about where to put stuff (strangely ignoring existing conventions for such things), but there isn't anything to put wherever we decide to put it! I just don't get it... something seems to be motivating this that hasn't come out yet. > The reasons I thought that it should be a separate component versus > the webapp are: > 1. It is, as David says, different in that it's mostly client side > libraries with maybe a few servlet methods, so there's not too much > overlap between the two. Over time different people might get > involved with it than with the OFBiz webapp framework. That's not what I meant at all... What I meant is that there is no reason to treat this stuff in a special way. It is confusing and breaking existing conventions will make things harder to find in general There are existing places for all of these things: - the client side stuff should go with all of the other client side stuff in the images component - the server side stuff that is generic (like jar files, wrapper classes, generic servlets or events) should go with other such things in the webapp or similar components - application specific use the both client and server side things would go in their specific components, like in the party, order, and other components > 2. If it's a separate component, it might be easier for people who > are using different versions of OFBiz to pull it into whatever > version they're working with. Is this the real motivation for doing a separate component? Is the hope to just create resources that can be used in older versions of OFBiz? I don't see how that can work any way for specific applications of the stuff. The libraries, no matter where they are, should be copy-able into older versions. > 3. Also, since it's mostly client-side stuff, it'd require a <webapp > > defined in its ofbiz-component.xml. I wasn't sure whether it was > a good idea to have a <webapp> defined inside of the webapp/ component. Yeah, I guess I wasn't very clear about when I mentioned this alternative previously. The client side static stuff would probably be best where other client side static stuff is, as I mentioned above. -David _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
Ok,
but if we go this route (i.e. adding things to the existing components) the new Ajax screens should be stable enough (not experimental): all the experimental stuff should be made outside of svn (mailing list, Jira etc...), a bit more difficult but not impossible. Jacopo David E. Jones wrote: > > Si Chen wrote: >> It's great to get all this feedback. >> >> The reason I proposed that we should have a component for ajax- >> related work in OFBiz is so that it becomes a central point for >> collaboration on it. Of course, one of the first steps would be to >> find out what other developers have done and identify the right >> framework(s). Once we do have those discussions, though, it would be >> nice to have a place to put things so people could start >> experimenting with it and see it in action. By having a repository >> for it, that becomes possible, and I think that's very important to >> make ajax actionable in OFBiz, rather than just a point of >> discussion. That's why I'm proposing a repository component for it >> first. > > There is _no_ reason I can see that this is not actionable right now. We don't need a special component for it, or even commit access. > > So far we've spent all of this time talking about where to put stuff (strangely ignoring existing conventions for such things), but there isn't anything to put wherever we decide to put it! I just don't get it... something seems to be motivating this that hasn't come out yet. > >> The reasons I thought that it should be a separate component versus >> the webapp are: >> 1. It is, as David says, different in that it's mostly client side >> libraries with maybe a few servlet methods, so there's not too much >> overlap between the two. Over time different people might get >> involved with it than with the OFBiz webapp framework. > > That's not what I meant at all... What I meant is that there is no reason to treat this stuff in a special way. It is confusing and breaking existing conventions will make things harder to find in general > > There are existing places for all of these things: > > - the client side stuff should go with all of the other client side stuff in the images component > > - the server side stuff that is generic (like jar files, wrapper classes, generic servlets or events) should go with other such things in the webapp or similar components > > - application specific use the both client and server side things would go in their specific components, like in the party, order, and other components > >> 2. If it's a separate component, it might be easier for people who >> are using different versions of OFBiz to pull it into whatever >> version they're working with. > > Is this the real motivation for doing a separate component? Is the hope to just create resources that can be used in older versions of OFBiz? I don't see how that can work any way for specific applications of the stuff. The libraries, no matter where they are, should be copy-able into older versions. > >> 3. Also, since it's mostly client-side stuff, it'd require a <webapp >> > defined in its ofbiz-component.xml. I wasn't sure whether it was >> a good idea to have a <webapp> defined inside of the webapp/ component. > > Yeah, I guess I wasn't very clear about when I mentioned this alternative previously. The client side static stuff would probably be best where other client side static stuff is, as I mentioned above. > > -David > > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
Jacopo Cappellato wrote: > Ok, > > but if we go this route (i.e. adding things to the existing components) > the new Ajax screens should be stable enough (not experimental): all the > experimental stuff should be made outside of svn (mailing list, Jira > etc...), a bit more difficult but not impossible. > > Jacopo How is that different from how it's always been done? -David _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
In reply to this post by davidnwelton
David Welton wrote:
>> Like David says, AJAX is just a currently popular label for a bunch of >> older technologies, all of which are used in some form already. > > Here's a fun, if simplistic example: > > http://demo.script.aculo.us/shop > > (Check out the clean, simple ruby on rails source code too:-) > Actually, that drag and drop demo is primitive. I had to write a much better drag and drop system for a hobby application, implemented in Ruby on Rails of course. I'm a long time Ruby user and have a project and some contributions to that community. :) Back to the original topic. It certainly is more logical to split ajax where it's needed. If the form widgets are to be ajax enhanced, it should go under widgets/ in an appropriate place. The problem with this is commit privileges: If someone without serious intent to develop ajax doesn't get to commit, then OFBiz simply won't get ajax. I didn't think this would happen, which is why I proposed having ajax/ as a base framework component where all the dirty work can be done without affecting ofbiz as a whole. Also, I'm not sure many people see the forest for the trees with regards to Ajax. It's not just about the technology, but the granularity of the View layer in OFBIZ. So far, OFBiz has what I consider to be a very static-page oriented View. You can't write a GTK skin based on the current View layer, you'd have to rip out all the screens and rewrite them so that there are more smaller components that update only a portion of the GUI. And it might be that the screen widget system is inadequate for this as it currently stands. So I suspect that there will be many improvements to the view layer that would be made during the ajax effort which would benefit other Views like GTK. So this isn't just about Ajax, it's also about the View layer which I've been hoping to improve tremendously. With a very good one, we'll probably drive adoption of ofbiz into the stratosphere. :) - Leon _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
In reply to this post by David E. Jones
David,
it's not different at all from how it's always been done. And, frankly speaking, I'd prefer this approach instead of granting commit access to the applications and framework parts to new developers (that could have Ajax skills but not OFBiz skills) to let them make their tests. Jacopo David E. Jones wrote: > Jacopo Cappellato wrote: >> Ok, >> >> but if we go this route (i.e. adding things to the existing components) >> the new Ajax screens should be stable enough (not experimental): all the >> experimental stuff should be made outside of svn (mailing list, Jira >> etc...), a bit more difficult but not impossible. >> >> Jacopo > > How is that different from how it's always been done? > > -David > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
In reply to this post by Leon Torres-2
Leon,
please see my comments below: Leon Torres wrote: > > Actually, that drag and drop demo is primitive. I had to write a much better > drag and drop system for a hobby application, implemented in Ruby on Rails of > course. I'm a long time Ruby user and have a project and some contributions to > that community. :) > > Back to the original topic. It certainly is more logical to split ajax where > it's needed. If the form widgets are to be ajax enhanced, it should go under > widgets/ in an appropriate place. The problem with this is commit privileges: > If someone without serious intent to develop ajax doesn't get to commit, then > OFBiz simply won't get ajax. I didn't think this would happen, which is why I > proposed having ajax/ as a base framework component where all the dirty work can > be done without affecting ofbiz as a whole. > Are you saying that we should grant commit privileges (to work on the Ajax integration in OFBiz) also to persons not seriously motivated? I don't agree with this: if there are Ajax developers seriously interested in working in the OFBiz project, I'm sure that they will contribute a lot of patches that, with the committers' help/review/feedback could go into the public svn; however the review made by expert contributors is mandatory. I can't believe that the lack of commit grants will induce motivated contributors to refrain from sending their patches. On the other hand, if one guy is not so motivated, I think it could be dangerous (or at least useless) to grant him commit privileges. > Also, I'm not sure many people see the forest for the trees with regards to > Ajax. It's not just about the technology, but the granularity of the View layer > in OFBIZ. So far, OFBiz has what I consider to be a very static-page oriented > View. You can't write a GTK skin based on the current View layer, you'd have to > rip out all the screens and rewrite them so that there are more smaller > components that update only a portion of the GUI. And it might be that the > screen widget system is inadequate for this as it currently stands. > So I suspect that there will be many improvements to the view layer that would be > made during the ajax effort which would benefit other Views like GTK. > By my experience, the screen widget is a great tool to implement ui for an ERP system. However I'm sure that it can be improved. However I don't think that the new Ajax skilled committers could have the ability to do such improvements in the right way without the scrutiny of an expert committer. Jacopo > So this isn't just about Ajax, it's also about the View layer which I've been > hoping to improve tremendously. With a very good one, we'll probably drive > adoption of ofbiz into the stratosphere. :) > > - Leon > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
One way of handling big integrations from a new person might be:
1) "This is how I'm going to build it" - the new guy - so that people know what's going to happen, and don't have as much room for objection after he's dedicated a lot of time to the project. 2) Build it - so that people can see what it looks like and how it works. More action, less talk:-) 3) Fine tune as needs be. In this case it's definitely a project that requires both specialized OFBiz knowledge, as well as Ajax/javascript knowledge. 4) Commit it - existing committer who agrees to dedicate some time to review and understand the new code. 5) Cycle through steps 2-4 until people are comfortable with the new guy and committ access is handed out. Just a suggestion though - I don't think it's common practice to hand out commit access on the hope that good things will come of it, but for big projects, you also have to agree to dedicate some time to them beyond just looking at a patch now and then. -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/ _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
I think this approach has precedent.
If I remember correctly from the conference videos, Brett Palmer's entity engine stuff was handled in this way... - Andrew On Thu, 2006-06-15 at 09:43 +0200, David Welton wrote: > One way of handling big integrations from a new person might be: > > 1) "This is how I'm going to build it" - the new guy - so that people > know what's going to happen, and don't have as much room for objection > after he's dedicated a lot of time to the project. > > 2) Build it - so that people can see what it looks like and how it > works. More action, less talk:-) > > 3) Fine tune as needs be. In this case it's definitely a project that > requires both specialized OFBiz knowledge, as well as Ajax/javascript > knowledge. > > 4) Commit it - existing committer who agrees to dedicate some time to > review and understand the new code. > > 5) Cycle through steps 2-4 until people are comfortable with the new > guy and committ access is handed out. > > Just a suggestion though - I don't think it's common practice to hand > out commit access on the hope that good things will come of it, but > for big projects, you also have to agree to dedicate some time to them > beyond just looking at a patch now and then. > Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
In reply to this post by Leon Torres-2
>
> So this isn't just about Ajax, it's also about the View layer which I've been > hoping to improve tremendously. With a very good one, we'll probably drive > adoption of ofbiz into the stratosphere. :) > Very well said Leon! -florin Leon Torres wrote: > David Welton wrote: > >> Like David says, AJAX is just a currently popular label for a bunch of > >> older technologies, all of which are used in some form already. > > > > Here's a fun, if simplistic example: > > > > http://demo.script.aculo.us/shop > > > > (Check out the clean, simple ruby on rails source code too:-) > > > > Actually, that drag and drop demo is primitive. I had to write a much better > drag and drop system for a hobby application, implemented in Ruby on Rails of > course. I'm a long time Ruby user and have a project and some contributions to > that community. :) > > Back to the original topic. It certainly is more logical to split ajax where > it's needed. If the form widgets are to be ajax enhanced, it should go under > widgets/ in an appropriate place. The problem with this is commit privileges: > If someone without serious intent to develop ajax doesn't get to commit, then > OFBiz simply won't get ajax. I didn't think this would happen, which is why I > proposed having ajax/ as a base framework component where all the dirty work can > be done without affecting ofbiz as a whole. > > Also, I'm not sure many people see the forest for the trees with regards to > Ajax. It's not just about the technology, but the granularity of the View layer > in OFBIZ. So far, OFBiz has what I consider to be a very static-page oriented > View. You can't write a GTK skin based on the current View layer, you'd have to > rip out all the screens and rewrite them so that there are more smaller > components that update only a portion of the GUI. And it might be that the > screen widget system is inadequate for this as it currently stands. So I > suspect that there will be many improvements to the view layer that would be > made during the ajax effort which would benefit other Views like GTK. > > So this isn't just about Ajax, it's also about the View layer which I've been > hoping to improve tremendously. With a very good one, we'll probably drive > adoption of ofbiz into the stratosphere. :) > > - Leon > > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev > > > > > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Re: Dev - Proposal for Ajax enhanced OFbiz
|
|
In reply to this post by Leon Torres-2
Hello there
I am new to dev list, but let me express some thoughts about Ajax and OfBiz. We need Ajax in OfBiz. Shortly, because, if we have a best-breed technology in our hands, that's NIL if we cannot make it appealing to our customers. And Ajax, now, is the most efficient way to put usability in front of our clients. We should not see Ajax as an enemy, but more as the missing brick which will push OfBiz in the mainstream. Of course, as said by others earlier on this subject, it's important to choose the best suited framework, not if or why Ajax should be part of OfBiz. By the way, RIA is present already in OfBiz, in the form of Laszlo. Why Laszlo and not our best choice of Ajax framework? Now, let me enumerate some possible Open Source contenders (random order): Frameworks 1. Rico (http://www.openrico.org/rico/home.page) 2. ZK (http://zk1.sourceforge.net/) 3. Echo2 (http://www.nextapp.com/platform/echo2/echo/) 4. jWic (http://www.jwic.de/home/index.htm) Toolkits 1. Dojo (http://dojotoolkit.org/) 2. Prototype (http://prototype.conio.net/) 3. Script.aculo.us (http://script.aculo.us/) I think the core-developers should check in principle the architecture of the above, and any other proposals, to see the compatibility with OfBiz and maybe possible constrains, and then a would-be team of Ajax developers to sandbox further all shortlisted frameworks. Then focus on one framework and work further. Sorry for keeping you this long. Regards, Bogdan Susala [hidden email] _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |