Re: Oracle tips

[Jacopo Cappellato]

This is a pain actually... I will try to find out if I can retrieve that from 
somewhere.

Jacopo

On Feb 27, 2010, at 12:23 AM, Jacques Le Roux wrote:

> Hi Jacopo,
> 
> During the wiki migration we have lost these tips, are they still of some 
> value? Do you have still them available somewhere?
> http://olddocs.ofbiz.org/display/~jacopoc/OFBiz+and+Oracle
> Thanks
> 
> Jacques
> 
> 

Re: JobInvoker crashes while reading serviceengine.xml

[Adrian Crum]

Florin,

I have been unable to duplicate your problem. Have you changed the contents of 
serviceengine.xml? That is the only thing I can think of that would cause the 
error message you are getting.

-Adrian

--- On Wed, 2/24/10, Adrian Crum  wrote:

> From: Adrian Crum 
> Subject: Re: JobInvoker crashes while reading serviceengine.xml
> To: user@ofbiz.apache.org
> Date: Wednesday, February 24, 2010, 1:06 PM
> Florin,
> 
> Thank you for the information. I believe there might be a
> problem in the way things are cached. I will look into it
> further.
> 
> For now, if clearing the cache solves your problem then go
> ahead and do that. The long term solution will be to find
> out what is causing the problem and fix it.
> 
> -Adrian
> 
> 
> Florin Popa wrote:
> > Now I can confirm it fixes the problem. While I do
> that clear cache for resourceLoader I get few lines similar
> with the ones mentioned before, like
> > 
> > 2010-02-23 21:27:09,238 (default-invoker-Thread-498)
> [     
>    JobInvoker.java:267:ERROR] Problems
> reading values from serviceengine.xml file
> [java.lang.NumberFormatException: null]. Using defaults.
> > 
> > BUT the main advantage is that server does not fully
> crash and it recovers well. I do those calls on regular
> bases every 10 mins..
> > 
> > I only ask myself if (depending on the number of
> concurrent users) it needs to be done more often?! Could
> reach other side effects by doing it more often?
> > 
> > Best regards,
> > Florin
> >> I still need to know if that fixed the problem. If
> it did, then we need to look into it further to get it
> fixed.
> >> 
> >> -Adrian
> >> 
> >> Florin Popa wrote:
> >>> Hello Adrian,
> >>> 
> >>> Many thanks. Now I have the first feeling that
> it really helps!
> >>> It can be checked only in the evening because
> during the day I am doing clear all cache on regular basees
> for other other reasons (external process making updates to
> products and lucene index)
> >>> So now I did it manually, I need further to
> integrate it into a cronjob doing it every 30 mins maybe
> >>> 
> >>> Many thanks,
> >>> Florin
>  Florin,
>  
>  The next time you have that problem, try
> clearing the "resource.ResourceLoaders" cache and see if the
> problem goes away.
>  
>  -Adrian
>  
>  Florin Popa wrote:
> > Hello all,
> > 
> > I think I tried before to ask that
> question, but I would retry because it becomes a critical
> issue in production.
> > 
> > The Ofbiz instance runs fine for
> several ours and unexpectedly I can see these lines below in
> the log file. As soon as it starts with those exceptions, I
> need to restart the instance because nothing works further.
> > I can say that I never developed any
> additional/new Ofbiz Job and I also stopped some of them
> which I was sure that are never used for my purposes.
> > I also tried to upgrade the parser,
> but nothing helps by now:
> > 
> > 
> > 
> > Exception in thread
> "default-invoker-Thread-499" java.lang.NullPointerException
> >        at
> org.apache.xerces.dom.DeferredElementNSImpl.synchronizeData(Unknown
> Source)
> >        at
> org.apache.xerces.dom.ElementImpl.getNodeName(Unknown
> Source)
> >        at
> org.ofbiz.base.util.UtilXml.firstChildElement(UtilXml.java:436)
> > 2010-02-23 21:27:09,238
> (default-invoker-Thread-497) [     
>    JobInvoker.java:267:ERROR] Problems
> reading values from serviceengine.xml file
> [java.lang.NumberFormatException: null]. Using defaults.
> >        at
> org.ofbiz.service.config.ServiceConfigUtil.getXmlRootElement(ServiceConfigUtil.java:48)
> 
> >        at
> org.ofbiz.service.config.ServiceConfigUtil.getElement(ServiceConfigUtil.java:55)
> 
> >        at
> org.ofbiz.service.config.ServiceConfigUtil.getElementAttr(ServiceConfigUtil.java:63)
> 
> >        at
> org.ofbiz.service.job.JobInvoker.getTTL(JobInvoker.java:265)
> >        at
> org.ofbiz.service.job.JobInvoker.run(JobInvoker.java:255)
> >        at
> java.lang.Thread.run(Thread.java:619)
> > 2010-02-23 21:27:09,238
> (default-invoker-Thread-498) [     
>    JobInvoker.java:267:ERROR] Problems
> reading values from serviceengine.xml file
> [java.lang.NumberFormatException: null]. Using defaults.
> > 2010-02-23 21:27:09,238
> (default-invoker-Thread-496) [     
>    JobInvoker.java:267:ERROR] Problems
> reading values from serviceengine.xml file
> [java.lang.NumberFormatException: null]. Using defaults.
> > 2010-02-23 21:27:09,239
> (default-invoker-Thread-498) [     
>    JobInvoker.java:267:ERROR] Problems
> reading values from serviceengine.xml file
> [java.lang.NumberFormatException: null]. Using defaults.
> > 2010-02-23 21:27:09,239
> (default-invoker-Thread-497) [     
>    JobInvoker.java:267:ERROR] Problems
> reading values from serviceengine.xml file
> [java.lang.NumberFormatException: null]. Using defaults.
> > 2010-02-23 21:27:09,239
> (default-invoker-Thread-4

Re: Support of german locale

[Brajesh Patel]

Hi Sebi,

I think following will help you for change date formate.

<#assign date =
Static["java.text.DateFormat"].getDateInstance(Static["java.text.DateFormat"].LONG,
locale).format((date)!) />


On Fri, Feb 26, 2010 at 9:12 PM, Patrick wrote:

> Hi Sebi,
> I'm formatting my dates with code like this
> description="${bsh:openDate.tostring().substring(5,7)}"
>
> Maybe you will find it helpful.  Good luck
> patrick
>
> On Fri, Feb 26, 2010 at 1:31 AM, Sebi  wrote:
> >
> > Hi,
> >
> > I am new at "ofbiz" and evaluating the framework.
> >
> > I wonder if it is possible for users to type in a german date-format. It
> > still looks like this:
> >
> > http://n4.nabble.com/file/n1570247/Birthdate.png
> >
> > I surely changed the preferences to locale "de_DE" - I also started the
> > ofBiz-server under a german locale.
> >
> > The (label-)output of date/times is often not formattet:
> >
> > http://n4.nabble.com/file/n1570247/updated.png
> >
> > what can be done by
> >
> >${partyContactMech.fromDate?date?string.short}
> >
> > insted of
> >
> >${partyContactMech.fromDate}
> >
> > But I found no way to manage dates in inputfields in a similar way.
> >
> > Thank you for your help, I hope my english is ok so far...
> > Sebi
> > --
> > View this message in context:
> http://n4.nabble.com/Support-of-german-locale-tp1570247p1570247.html
> > Sent from the OFBiz - User mailing list archive at Nabble.com.
> >
>



-- 
Thanks
Brajesh Patel

HotWax Media
http://www.hotwaxmedia.com

Re: Now Practice Application will also teach you, how to write ajax request using prototype library in OFBiz

[Brajesh Patel]

+1

On Fri, Feb 26, 2010 at 6:54 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks Divesh, Arun and Rishi,
>
> This will be much appreciated by everybody I'm sure
>
> Jacques
>
> From: "Divesh Dutta" 
>
>  Hello Users,
>>
>> I have introduced  new section in Practice application of OFBiz , which is
>> all about "How to write Ajax request".  By following this  a newbie can
>> learn  writing ajax request and enabling client side validation by using
>> prototype library.
>>
>> All above stuffs  are available in newly introduced "part-6" of practice
>> application in following link:
>> http://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide
>>
>> I would like to thanks Arun Patidar for support and Rishi Solanki for idea
>> of introducing this section.
>>
>> Thanks
>> --
>> Divesh Dutta.
>>
>>
>


-- 
Thanks
Brajesh Patel

HotWax Media
http://www.hotwaxmedia.com

Oracle tips

[Jacques Le Roux]

Hi Jacopo,

During the wiki migration we have lost these tips, are they still of some 
value? Do you have still them available somewhere?
http://olddocs.ofbiz.org/display/~jacopoc/OFBiz+and+Oracle


Thanks

Jacques

Re: EC_DEFAULT

[BJ Freeman]

EC_DEFAULT is the old parms for ecommers
you can find the data in
specialpurpose/ecommerce/data/EcommerceTypeData.xml

MULTIFLEX is the only other theme for Ecommerce. this is defined by
visualThemeSetId


if you want to create a new ecommerce theme you can copy the MULTIFLEX
and rename it in the themes folder.

or
you can load
https://issues.apache.org/jira/browse/OFBIZ-3490
into your build it it will copy the multiplex to the new theme folder
you define.
then you can modify the data for your own theme.
note, the script only copies basic files so check that all files you
want are copied.


Alexander1893 sent the following on 2/26/2010 12:54 PM:
> Hi all,
> 
> when I want to change to theme of a store I have the following choices in
> the back-end:
> 
>> EC_DEFAULT
>> MULTIFLEX
> 
> I have two questions:
> 
>> Where can I see what the "EC_DEFAULT" is?
>> Why "Multiflex" is shown and not the other themes I have (e.g.
>> "bluelight")
> 
> Thanks a lot for an help!
> Alexander

Re: Was Community-Driven OFBiz a Mistake? (was: Re: OpenERP fund raising)

[Matt Warnock]

On Thu, 2010-02-25 at 10:50 -0700, David E Jones wrote:
> Matt,
> 
> You might be interested to hear that early in the life of OFBiz, and
>  after technology investing recovered from the lull in 2000-2001, I was
>  approached by a number of investors who wanted to turn OFBiz into a
>  commercial open source project instead of a community-driven one
>  (which would require a change in licensing to the GPL or something
>  similar so that end-users would have an incentive to purchase
>  licenses; would also require centralizing and/or license value added
>  services instead of pushing for an open playing field). However, my
>  intent from the beginning was to have OFBiz be a community-driven
>  project so I stuck with that.
> 
> Perhaps that was a mistake?

I don't think so, but others may.

> About this comment: "So if you want an OFBiz solution, pay us and we'll
>  get you a custom OFBiz solution-- otherwise, don't waste our time."
>  That's pretty insulting and low-brow. If that were really the case
>  then people who abandon other ERP software to work on OFBiz wouldn't
>  be doing so because it is easier to customize... and yes, that is the
>  main reason I hear from those experienced with other ERP software.
>  Also, there would be no attempts whatsoever at documentation, and
>  instead there are thousands of pages of it (in fact, probably too much
>  for most people, making it harder to find the info they want, leading
>  to complaints of no documentation when the fact is they just haven't
>  bothered to read it).

I'm sorry if it came across as insulting, it was not intended so, but is
is a very real theme I hear in this forum, usually in the form of "yeah,
that'd be nice, but who's gonna pay for it?"  There does seem to be a
culture of scarcity around OFBiz right now-- that I'd like to see
changed. I'm not recriminating or blaming-- I think it's perfectly
natural given the history to date.  You haven't gotten rich and famous
from OFBiz yet, despite a LOT of effort (and accomplishment).

> Take a look at the OFBiz service providers page and the PMC and
>  committers page and see how much overlap there is between them. Here's
>  the spoiler: there isn't much overlap at all. The vast majority of
>  service providers never contribute back to the project. The vast
>  majority of the business around OFBiz results in profit that
>  contributors never see a penny of. If I were to estimate I'd say it's
>  probably only 1-2% of the money that gets back to the smaller group
>  that contributes 90% of the code. In other words, most of the
>  customization work is done by people who don't contribute to the
>  project, and who don't pay for training or any other sort of service.
>  They figure it out on their own for the most part.

Again, hoping to make the ROI with training beforehand puts the cart
before the horse.  Do you order a car sight unseen, with a big deposit
up front?  No, you go to a lot, take the test drive, maybe rent it, and
if it meets your needs, then maybe you place a custom order-- but more
likely you take delivery from dealer inventory.  Does that mean the
dealer got screwed, because he fronted the inventory?  No, he knows that
the sale is the BEGINNING of the relationship, not the END.  

Sure, some people will get on a waiting list for an exotic sight
unseen-- but you don't build a Ford, a GM or a Toyota company on that
model.  Nor do Autozone, Burt Brothers Tires and Joe's Auto Repair make
THEIR living on exotics.  The bigger the market penetration, the bigger
the economic environment.

> On the other hand, if you think you can get my time for free just
>  because I'm willing to share the intellectual property I create, then
>  you're in for some big disappointment! And how could it be any other
>  way?

Not looking for that, but look how much time you spend!  We had a saying
in the practice of law-- I'd rather be water-skiing and not getting paid
than working and not getting paid.  With a larger community (still
community-driven), you get a larger income AND a life.  I'm trying to
help you see the vision that the community CAN be bigger, but probably
not with the present methods.  If you do what you've always done, you'll
get what you've always gotten.  I'm envisioning a quantum-leap, not an
incremental gain in market share.

> So here we go... we've got a community-driven project and people want
>  it to be a commercial project. I've been pushing for years for
>  community-driven software and trying to attract developers to help
>  build this thing, and for some history about that and concepts related
>  to it please see my blog:
> 
> http://osofbiz.blogspot.com/

I read this before.  And I don't think people want it to be a commercial
project, necessarily.  They just want it to be 1) more popular (like
being used by more people) and 2) easier to initially use and learn
(which helps a lot with #1).
  
> There are a number of posts on this topic, and this one might be of
>  particular inter

EC_DEFAULT

[Alexander1893]

Hi all,

when I want to change to theme of a store I have the following choices in
the back-end:

> EC_DEFAULT
> MULTIFLEX

I have two questions:

> Where can I see what the "EC_DEFAULT" is?
> Why "Multiflex" is shown and not the other themes I have (e.g.
> "bluelight")

Thanks a lot for an help!
Alexander
-- 
View this message in context: 
http://n4.nabble.com/EC-DEFAULT-tp1571320p1571320.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[huang.mi...@gmail.com]

On Fri, 2010-02-26 at 09:22 -0800, BJ Freeman wrote:
> 
> huang.mi...@gmail.com sent the following on 2/26/2010 8:45 AM:
> > On Fri, 2010-02-26 at 09:06 -0500, Ruth Hoffman wrote:
> >> How about the seamless and transparent database support by way of the 
> >> Entity Engine?  If you want to develop an application or implement
> >> ERP, 
> >> then you don't need to worry about the database. You don't need to 
> >> stress over whether to use Hiberanate or JDO or native SQL or
> >> whatever 
> >> the latest database technology fad happens to be. The EE is here, its 
> >> proven and best of all I don't have to deal with it! I can get on to 
> >> developing my applications.
> >>
> > I'm sorry to say this is also a Grails built in feature. Grails can
> > simply write the domain model as a Groovy bean. Just give a really
> > feature rich and yet simple example:
> > class Person {
> >   String pid
> >   String firstName
> >   String lastName
> >   BigDecimal salary
> >   Date birthday
> >   String notes
> > 
> >   static constraints = {
> >  pid(blank:false, unique: true)
> >  firstName(blank:false)
> >  lastName(blank:false)
> >  notes(blank:true, nullable:true, maxSize:5000)
> >   }
> > 
> > }
> > This is all the code you need to write to define a entity model, then
> > CRUD methods, nearly every possible simple finder methods (up to 2
> Actually once you define the enity, CRUD is atomatically genterated.
> 
> > fields composite criteria), auto SQL table DML maintenance with re-sync
> what you call re-sync is done at restart of ofbiz
> > ability on every time you change the model, are all ready for you. You
> > can also add some constraints for validation logic and storage hint
> > (most have default value so you don't need to code for every one), just
> > declaration, that's enough.
> how is that different than ofbiz which also updates the UI with changes
> to the entity.
Sorry I haven't mentioned this. Grails scaffolding mechanism can
generate UI based on the domain model define, with validation, and
reflect the changes if you have made.


> > Constraints check are available on presentation/service/persistence
> > tier. Quite like OFBIZ entity engine, but more coding efficient, isn't
> > it?
> using the mini language is more efficient.
> 
I haven't touch much of the mini-lang part yet. What I've demoed is the
equivalence of the OFBIZ entity definition XML plus validation code
written in mini-lang events.

> > And the sophisticated model relation management and auto
> > optimized-locking mechanism, which seems to be a weak point of OFBIZ
> > entity engine.
> > 
> >> Or all the framework tools that have been integrated and proven. 
> >> Everything from Internationalization and localization support to XML 
> >> document handling. (Personally, I'm tired of having to integrate XML 
> >> parsers every time I need that functionality in an application.)
> how is that different than ofbiz?
> >>
> >>
> > XML process, persistence, i18n support, are all readily built in Grails
> > platform. 
> again how is that different than ofbiz other than how it is accomplished?
> > 
> > 

I'm only try following the question and answer of Christopher has raised:
"I was hoping that my question would get ofbiz supporters to list some of 
the benefits of ofbiz over grails." So sorry no much "grails over ofbiz"
here ;-)

deployment with files synchronization

[Florin Popa]

Hello all,

Considering a deployment scheme with 2 ofbiz instances, running on 
separate physical machines, has anyone experienced http://www.drbd.org/ 
or any other similar tool?

Any suggestion for something in this area?


thanks,
Florin

Re: Retrieving context from the HttpServletRequest request, is it possible?

[Scott Gray]

What are you trying to do with the context once you get it?

If you want to put a value in the context then all you can do at the event 
stage is to add it as a request attribute.
If you want to get a value from the "context" (it doesn't really exist yet at 
this stage) then your best bet is to use the UtilHttp.getCombinedMap(...) 
method.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 26/02/2010, at 11:13 AM, Ghosty wrote:

> 
> I know you can get at the request from the context, but is it possible to do
> it vice versa?
> 
> I've tried all sorts of request.getAttribute("context") in hopes it might
> have been stuffed in there too.
> 
> Basically in my controller.xml I have a requestmap event type java
> triggering a method which comes in as the HttpServletRequest request and I
> want to get at the context to pass on to some other methods.
> 
> Thanks.
> -- 
> View this message in context: 
> http://n4.nabble.com/Retrieving-context-from-the-HttpServletRequest-request-is-it-possible-tp1571081p1571081.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.



smime.p7s
Description: S/MIME cryptographic signature

Retrieving context from the HttpServletRequest request, is it possible?

[Ghosty]

I know you can get at the request from the context, but is it possible to do
it vice versa?

I've tried all sorts of request.getAttribute("context") in hopes it might
have been stuffed in there too.

Basically in my controller.xml I have a requestmap event type java
triggering a method which comes in as the HttpServletRequest request and I
want to get at the context to pass on to some other methods.

Thanks.
-- 
View this message in context: 
http://n4.nabble.com/Retrieving-context-from-the-HttpServletRequest-request-is-it-possible-tp1571081p1571081.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[BJ Freeman]

The only thing I see differet about grails is it use ROR. There was some
integration of ROR in ofbiz but the motivator has since stopped and no
more effort has been done. check out Davids response
http://www.mail-archive.com/ofbiz-...@incubator.apache.org/msg01688.html

maybe picking up where that left off would be the best implantations step.

huang.mi...@gmail.com sent the following on 2/26/2010 8:49 AM:
> Grails can also provides these ability, which is the fundamental spirit
> of "Rails" development environment, namely RoR, Grails.
> 
> On Fri, 2010-02-26 at 15:34 +0100, Jacques Le Roux wrote:
>> Also OFBiz is *great* when it comes to *not* compile, reboot, compile,
>> reboot, compile, reboot, compile, reboot, compile, reboot, 
>> compile, reboot, OK you see...
>>
>>
> 
> 

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Ruth Hoffman]

Cool! Who knew.

Still, in OFBiz I don't even have to write the Person class. Its already 
there. I don't even need to find a database and load the schema. All 
that happens for me transparently. If I let it.


Ruth


huang.mi...@gmail.com wrote:

On Fri, 2010-02-26 at 09:06 -0500, Ruth Hoffman wrote:
  
How about the seamless and transparent database support by way of the 
Entity Engine?  If you want to develop an application or implement
ERP, 
then you don't need to worry about the database. You don't need to 
stress over whether to use Hiberanate or JDO or native SQL or
whatever 
the latest database technology fad happens to be. The EE is here, its 
proven and best of all I don't have to deal with it! I can get on to 
developing my applications.




I'm sorry to say this is also a Grails built in feature. Grails can
simply write the domain model as a Groovy bean. Just give a really
feature rich and yet simple example:
class Person {
  String pid
  String firstName
  String lastName
  BigDecimal salary
  Date birthday
  String notes

  static constraints = {
 pid(blank:false, unique: true)
 firstName(blank:false)
 lastName(blank:false)
 notes(blank:true, nullable:true, maxSize:5000)
  }

}
This is all the code you need to write to define a entity model, then
CRUD methods, nearly every possible simple finder methods (up to 2
fields composite criteria), auto SQL table DML maintenance with re-sync
ability on every time you change the model, are all ready for you. You
can also add some constraints for validation logic and storage hint
(most have default value so you don't need to code for every one), just
declaration, that's enough.
Constraints check are available on presentation/service/persistence
tier. Quite like OFBIZ entity engine, but more coding efficient, isn't
it?
And the sophisticated model relation management and auto
optimized-locking mechanism, which seems to be a weak point of OFBIZ
entity engine.

  
Or all the framework tools that have been integrated and proven. 
Everything from Internationalization and localization support to XML 
document handling. (Personally, I'm tired of having to integrate XML 
parsers every time I need that functionality in an application.)





XML process, persistence, i18n support, are all readily built in Grails
platform. 



  

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[David E Jones]

There is even a term for this: object-relational impedance mismatch.

Of course, that is true for many other things, like object-service impedance 
mismatch, object-XML impedance mismatch, etc, etc. It comes down to the simple 
idea that modeling everything as a custom object is full of problems. 

I agree Scott, this is definitely something worth researching for those into 
building enterprise systems.

-David


On Feb 26, 2010, at 10:13 AM, Scott Gray wrote:

> My point still stands, OFBiz intentionally does not use an ORM layer and if 
> the reasons behind that are not understood then any discussions about it are 
> going to be somewhat fruitless.
> 
> Regards
> Scott
> 
> On 26/02/2010, at 10:06 AM, huang.mi...@gmail.com wrote:
> 
>> Use Grails doesn't means bundle with Hibernate. Grails also supports
>> GORM-JPA combine, license compatible products such as OpenJPA can be
>> used instead. It can defer to the deploy time (thus up to end user) to
>> choose Hibernate or some other JPA implementation.
>> 
>> On Fri, 2010-02-26 at 09:00 -0700, Scott Gray wrote:
>>> Hi Chris
>>> 
>>> With all due respect, your desire to replace the entity engine with 
>>> hibernate exhibits a serious lack of understanding of one of OFBiz's core 
>>> design philosophies.  This has been discussed many times so I don't want to 
>>> rehash the debate here but I do strongly suggest that you search the 
>>> mailing lists for discussions pertaining to hibernate and ORM in general.
>>> 
>>> Regards
>>> Scott
>>> 
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>> 
>> 
>> 
> 

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[BJ Freeman]

huang.mi...@gmail.com sent the following on 2/26/2010 8:45 AM:
> On Fri, 2010-02-26 at 09:06 -0500, Ruth Hoffman wrote:
>> How about the seamless and transparent database support by way of the 
>> Entity Engine?  If you want to develop an application or implement
>> ERP, 
>> then you don't need to worry about the database. You don't need to 
>> stress over whether to use Hiberanate or JDO or native SQL or
>> whatever 
>> the latest database technology fad happens to be. The EE is here, its 
>> proven and best of all I don't have to deal with it! I can get on to 
>> developing my applications.
>>
> I'm sorry to say this is also a Grails built in feature. Grails can
> simply write the domain model as a Groovy bean. Just give a really
> feature rich and yet simple example:
> class Person {
>   String pid
>   String firstName
>   String lastName
>   BigDecimal salary
>   Date birthday
>   String notes
> 
>   static constraints = {
>  pid(blank:false, unique: true)
>  firstName(blank:false)
>  lastName(blank:false)
>  notes(blank:true, nullable:true, maxSize:5000)
>   }
> 
> }
> This is all the code you need to write to define a entity model, then
> CRUD methods, nearly every possible simple finder methods (up to 2
Actually once you define the enity, CRUD is atomatically genterated.

> fields composite criteria), auto SQL table DML maintenance with re-sync
what you call re-sync is done at restart of ofbiz
> ability on every time you change the model, are all ready for you. You
> can also add some constraints for validation logic and storage hint
> (most have default value so you don't need to code for every one), just
> declaration, that's enough.
how is that different than ofbiz which also updates the UI with changes
to the entity.
> Constraints check are available on presentation/service/persistence
> tier. Quite like OFBIZ entity engine, but more coding efficient, isn't
> it?
using the mini language is more efficient.

> And the sophisticated model relation management and auto
> optimized-locking mechanism, which seems to be a weak point of OFBIZ
> entity engine.
> 
>> Or all the framework tools that have been integrated and proven. 
>> Everything from Internationalization and localization support to XML 
>> document handling. (Personally, I'm tired of having to integrate XML 
>> parsers every time I need that functionality in an application.)
how is that different than ofbiz?
>>
>>
> XML process, persistence, i18n support, are all readily built in Grails
> platform. 
again how is that different than ofbiz other than how it is accomplished?
> 
> 

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Scott Gray]

My point still stands, OFBiz intentionally does not use an ORM layer and if the 
reasons behind that are not understood then any discussions about it are going 
to be somewhat fruitless.

Regards
Scott

On 26/02/2010, at 10:06 AM, huang.mi...@gmail.com wrote:

> Use Grails doesn't means bundle with Hibernate. Grails also supports
> GORM-JPA combine, license compatible products such as OpenJPA can be
> used instead. It can defer to the deploy time (thus up to end user) to
> choose Hibernate or some other JPA implementation.
> 
> On Fri, 2010-02-26 at 09:00 -0700, Scott Gray wrote:
>> Hi Chris
>> 
>> With all due respect, your desire to replace the entity engine with 
>> hibernate exhibits a serious lack of understanding of one of OFBiz's core 
>> design philosophies.  This has been discussed many times so I don't want to 
>> rehash the debate here but I do strongly suggest that you search the mailing 
>> lists for discussions pertaining to hibernate and ORM in general.
>> 
>> Regards
>> Scott
>> 
>> HotWax Media
>> http://www.hotwaxmedia.com
>> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[huang.mi...@gmail.com]

Use Grails doesn't means bundle with Hibernate. Grails also supports
GORM-JPA combine, license compatible products such as OpenJPA can be
used instead. It can defer to the deploy time (thus up to end user) to
choose Hibernate or some other JPA implementation.

On Fri, 2010-02-26 at 09:00 -0700, Scott Gray wrote:
> Hi Chris
> 
> With all due respect, your desire to replace the entity engine with hibernate 
> exhibits a serious lack of understanding of one of OFBiz's core design 
> philosophies.  This has been discussed many times so I don't want to rehash 
> the debate here but I do strongly suggest that you search the mailing lists 
> for discussions pertaining to hibernate and ORM in general.
> 
> Regards
> Scott
> 
> HotWax Media
> http://www.hotwaxmedia.com
> 

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[huang.mi...@gmail.com]

Grails can also provides these ability, which is the fundamental spirit
of "Rails" development environment, namely RoR, Grails.

On Fri, 2010-02-26 at 15:34 +0100, Jacques Le Roux wrote:
> Also OFBiz is *great* when it comes to *not* compile, reboot, compile,
> reboot, compile, reboot, compile, reboot, compile, reboot, 
> compile, reboot, OK you see...
> 
> 

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[huang.mi...@gmail.com]

On Fri, 2010-02-26 at 09:06 -0500, Ruth Hoffman wrote:
> How about the seamless and transparent database support by way of the 
> Entity Engine?  If you want to develop an application or implement
> ERP, 
> then you don't need to worry about the database. You don't need to 
> stress over whether to use Hiberanate or JDO or native SQL or
> whatever 
> the latest database technology fad happens to be. The EE is here, its 
> proven and best of all I don't have to deal with it! I can get on to 
> developing my applications.
> 
I'm sorry to say this is also a Grails built in feature. Grails can
simply write the domain model as a Groovy bean. Just give a really
feature rich and yet simple example:
class Person {
  String pid
  String firstName
  String lastName
  BigDecimal salary
  Date birthday
  String notes

  static constraints = {
 pid(blank:false, unique: true)
 firstName(blank:false)
 lastName(blank:false)
 notes(blank:true, nullable:true, maxSize:5000)
  }

}
This is all the code you need to write to define a entity model, then
CRUD methods, nearly every possible simple finder methods (up to 2
fields composite criteria), auto SQL table DML maintenance with re-sync
ability on every time you change the model, are all ready for you. You
can also add some constraints for validation logic and storage hint
(most have default value so you don't need to code for every one), just
declaration, that's enough.
Constraints check are available on presentation/service/persistence
tier. Quite like OFBIZ entity engine, but more coding efficient, isn't
it?
And the sophisticated model relation management and auto
optimized-locking mechanism, which seems to be a weak point of OFBIZ
entity engine.

> Or all the framework tools that have been integrated and proven. 
> Everything from Internationalization and localization support to XML 
> document handling. (Personally, I'm tired of having to integrate XML 
> parsers every time I need that functionality in an application.)
> 
> 
XML process, persistence, i18n support, are all readily built in Grails
platform. 

Re: Pls dont ignore..plssss

[BJ Freeman]

I put the address to the user mailing you can send your further
questions there.
the ecommerce was moved to the specialpurpose folder

The image you need to change is in the framework/images/webapp/images


priya.ren...@gmail.com sent the following on 2/26/2010 7:00 AM:
>  Hi,
> 
>  first of all, if this is no the correct place to ask queries, pls give me
>  the location and id to send my query.
> 
>  I am very new to the ofbiz development.I took the release 09.04 code from
>  the location http://svn.apache.org/repos/asf/ofbiz/branches/release09.04/
> 
>  But there was no ecommerce folder in the application folder.
>  I was trying to change the logo in the ecommerce page.
> 
>  But i am not able to change the logo in the ecommerce main page. Since
>  there is no ecommerce folder in the application folder, where i have to
>  change. But i am able to chnage the logo in the manufacturing and catalog
>  modules.
> 
>  What i have to do..pls help  me..
> 
>  thanks
>  Priya
> 

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Christopher Snow]

There's a set of instructions at:

http://cwiki.apache.org/confluence/x/nYTW

Or I can send you a in progress hack of my latest attempt - it's 90mb.


Interesting work. Will future OFBIZ official release based on this
framework? Is there any preview working code in repository now?

  

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Christopher Snow]

.. and grails has many plugins : jBPM, drools, birt, quartz, rest, soap, 
etc that facilitate building enterprise systems.


huang.mi...@gmail.com wrote:

Please see inline...

On Fri, 2010-02-26 at 12:20 +, Christopher Snow wrote:
  

One more - inline...

Christopher Snow wrote:


Hi Miles,

I'm currently doing some work on making a standalone ofbiz development 
framework (i.e. no business functionality).  Your questions have got 
me thinking:


  

Interesting work. Will future OFBIZ official release based on this
framework? Is there any preview working code in repository now?

  
  "what does the ofbiz framework give you that the grails framework 
doesn't?"
  


Yes. That's why I've started this topic. Since someone is dedicated in
inventing wheel and do well, why OFBIZ keep home-made one?
Consider the maintenance effort you are currently spending. And consider
if OFBIZ will last another decade (I really hope so), how many effort
will spend in keeping OFBIZ catch on the new technology evolve, like
recently mentioned OSGi, etc...

  

A possible answer:

  "Ofbiz gives you a ready made layout for backend management UI (i.e. 
screens, menus, forms)"
  


Beg me to argue that This is a higher UI level functionality. Grails has
also its way to do UI-level component composition, based on decoration
pattern. For the real problem, see next section.

  
the ofbiz framework will give you an easy upgrade path to the full ofbiz 
and all its business functionality.


Yes, this is the first class factor. Although to write a new component
in Grails is trival, to provide the new Grails code all/most ability to
access the current OFBIZ business functionality and integrated it into
the current OFBIZ framework is really a big challenge. The problem
exists on every tier: persistence entity, service/event, widget. In
every tier OFBIZ has its unique implementation technology and OFBIZ
components seems to coupling on every tier, a little tight coupling, I
think. 

  
I can't think of anything other than this that the ofbiz framework 
provides that grails doesn't.


Cheers,

Chris

  



  

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Scott Gray]

Hi Chris

With all due respect, your desire to replace the entity engine with hibernate 
exhibits a serious lack of understanding of one of OFBiz's core design 
philosophies.  This has been discussed many times so I don't want to rehash the 
debate here but I do strongly suggest that you search the mailing lists for 
discussions pertaining to hibernate and ORM in general.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 26/02/2010, at 8:32 AM, Christopher Snow wrote:

> Hi Jacques,
> 
> Thanks for the comments.
> 
> Not sure how grails handles extension of artifacts (except that Controllers 
> and Services are classes so theoretically could be extended).
> 
> Grails only needs to be restarted when the hibernate definitions have changed 
> (I think). Controller and Service changes are dynamically reloaded in 
> development mode without a restart.
> 
> Grails has:  |"grails create-app helloworld" which is the equivalent of 
> creating an ofbiz component.
> 
> In ofbiz, I always have to jump into the ofbiz code, even if its just to 
> configure it (e.g. data sources).  In grails, the component configuration is 
> done in the component itself.  I would never expect you to modify the core 
> grails code and create patches to ship with your application - this is a big 
> disadvantage with ofbiz.
> 
> Please don't think I'm giving ofbiz a hard time.  Don't forget, I'm 
> interested in creating a standalone ofbiz framework (which would be 
> especially useful for my current government client), but I'm not sure that 
> the framework on it's own carrys any benefits compared to grails.  It's the 
> business applications that give ofbiz the most advantage.
> 
> Cheers,
> 
> Chris
> |
> 
> Jacques Le Roux wrote:
>> And one of the most important thing but not obvious in OFBiz,  extension and 
>> reutilisation of artifacts.
>> From hot-deploy, you can build your own applicaiton based on the trunk (or 
>> release but I'd recommend trunk for easier update later) without touching 
>> much of OFBiz itself. If you handle it right you may end with a couple of 
>> small patches. There are even small tools around, see ant - p, to deal with 
>> hat. This is where is the real OFBiz expertise, it takes some time to 
>> understand and use...
>> Also OFBiz is *great* when it comes to *not* compile, reboot, compile, 
>> reboot, compile, reboot, compile, reboot, compile, reboot, compile, reboot, 
>> OK you see...
>> 
>> Jacques
>> 
>> From: "Ruth Hoffman" 
>> 
>> 
>>> Hi Jacopo:
>>> 
>>> IMO, one should always give positive affirmations when responding to posts 
>>> like these. OFBiz has plenty of great things we can say that shouldn't 
>>> require much effort on your part to comment on:
>>> 
>>> How about the seamless and transparent database support by way of the 
>>> Entity Engine?  If you want to develop an application or implement ERP, 
>>> then you don't need to worry about the database. You don't need to stress 
>>> over whether to use Hiberanate or JDO or native SQL or whatever the latest 
>>> database technology fad happens to be. The EE is here, its proven and best 
>>> of all I don't have to deal with it! I can get on to developing my 
>>> applications.
>>> 
>>> Or the really cool Service Engine that lets me write reusable code. Java or 
>>> otherwise!
>>> 
>>> Or all the framework tools that have been integrated and proven. Everything 
>>> from Internationalization and localization support to XML document 
>>> handling. (Personally, I'm tired of having to integrate XML parsers every 
>>> time I need that functionality in an application.)
>>> 
>>> How hard is it to list some of these features? Take the "high road".
>>> 
>>> Ruth
>>> 
>>> 
>>> 
>>> Jacopo Cappellato wrote:
 On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:
 
 
> Hey come on Jacopo - overall I'm actually trying to promote the use of 
> ofbiz.  I've invested a considerable amount of time in it.
> 
> I was hoping that my question would get ofbiz supporters to list some of 
> the benefits of ofbiz over grails.
> 
> 
 
 Eh eh... this time your attempt will not help you to get easy information 
 (at least from me): you will have to do your own research :-)
 
 Jacopo
 
 
 
> Jacopo Cappellato wrote:
> 
>> On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:
>> 
>> 
 I can't think of anything other than this that the ofbiz framework 
 provides that grails doesn't.
 
>> If you are blind, all you can see is darkness.
>> 
>> Jacopo
>> 
>> 
 
 
 
>>> 
>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[huang.mi...@gmail.com]

Please see inline...

On Fri, 2010-02-26 at 12:20 +, Christopher Snow wrote:
> One more - inline...
> 
> Christopher Snow wrote:
> > Hi Miles,
> >
> > I'm currently doing some work on making a standalone ofbiz development 
> > framework (i.e. no business functionality).  Your questions have got 
> > me thinking:
> >
Interesting work. Will future OFBIZ official release based on this
framework? Is there any preview working code in repository now?

> >   "what does the ofbiz framework give you that the grails framework 
> > doesn't?"

Yes. That's why I've started this topic. Since someone is dedicated in
inventing wheel and do well, why OFBIZ keep home-made one?
Consider the maintenance effort you are currently spending. And consider
if OFBIZ will last another decade (I really hope so), how many effort
will spend in keeping OFBIZ catch on the new technology evolve, like
recently mentioned OSGi, etc...

> >
> > A possible answer:
> >
> >   "Ofbiz gives you a ready made layout for backend management UI (i.e. 
> > screens, menus, forms)"

Beg me to argue that This is a higher UI level functionality. Grails has
also its way to do UI-level component composition, based on decoration
pattern. For the real problem, see next section.

> the ofbiz framework will give you an easy upgrade path to the full ofbiz 
> and all its business functionality.
Yes, this is the first class factor. Although to write a new component
in Grails is trival, to provide the new Grails code all/most ability to
access the current OFBIZ business functionality and integrated it into
the current OFBIZ framework is really a big challenge. The problem
exists on every tier: persistence entity, service/event, widget. In
every tier OFBIZ has its unique implementation technology and OFBIZ
components seems to coupling on every tier, a little tight coupling, I
think. 

> >
> > I can't think of anything other than this that the ofbiz framework 
> > provides that grails doesn't.
> >
> > Cheers,
> >
> > Chris
> >

Re: temporal expression

[Christopher Snow]

Thanks Adrian.  Neat solution btw.

Adrian Crum wrote:

They are stable. The only potential changes are bug fixes.

-Adrian

Christopher Snow wrote:

Hi Forum/Adrian!

We are about to make heavy use of temporal expressions on trunk.  
Before we do, would you consider them stable at the moment?


Many thanks,

Chris

Re: temporal expression

[Adrian Crum]

They are stable. The only potential changes are bug fixes.

-Adrian

Christopher Snow wrote:

Hi Forum/Adrian!

We are about to make heavy use of temporal expressions on trunk.  Before 
we do, would you consider them stable at the moment?


Many thanks,

Chris

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Jacques Le Roux]

I'm more speaking at the business level . You may reuse artifacts there...

Jacques

From: "Christopher Snow" 



Hi Jacques,

Thanks for the comments.

Not sure how grails handles extension of artifacts (except that 
Controllers and Services are classes so theoretically could be extended).


Grails only needs to be restarted when the hibernate definitions have 
changed (I think). Controller and Service changes are dynamically 
reloaded in development mode without a restart.


Grails has:  |"grails create-app helloworld" which is the equivalent of 
creating an ofbiz component.


In ofbiz, I always have to jump into the ofbiz code, even if its just to 
configure it (e.g. data sources).  In grails, the component 
configuration is done in the component itself.  I would never expect you 
to modify the core grails code and create patches to ship with your 
application - this is a big disadvantage with ofbiz.


Please don't think I'm giving ofbiz a hard time.  Don't forget, I'm 
interested in creating a standalone ofbiz framework (which would be 
especially useful for my current government client), but I'm not sure 
that the framework on it's own carrys any benefits compared to grails.  
It's the business applications that give ofbiz the most advantage.


Cheers,

Chris
|

Jacques Le Roux wrote:
And one of the most important thing but not obvious in OFBiz,  
extension and reutilisation of artifacts.
From hot-deploy, you can build your own applicaiton based on the trunk 
(or release but I'd recommend trunk for easier update later) without 
touching much of OFBiz itself. If you handle it right you may end with 
a couple of small patches. There are even small tools around, see ant 
- p, to deal with hat. This is where is the real OFBiz expertise, it 
takes some time to understand and use...
Also OFBiz is *great* when it comes to *not* compile, reboot, compile, 
reboot, compile, reboot, compile, reboot, compile, reboot, compile, 
reboot, OK you see...


Jacques

From: "Ruth Hoffman" 



Hi Jacopo:

IMO, one should always give positive affirmations when responding to 
posts like these. OFBiz has plenty of great things we can say that 
shouldn't require much effort on your part to comment on:


How about the seamless and transparent database support by way of the 
Entity Engine?  If you want to develop an application or implement 
ERP, then you don't need to worry about the database. You don't need 
to stress over whether to use Hiberanate or JDO or native SQL or 
whatever the latest database technology fad happens to be. The EE is 
here, its proven and best of all I don't have to deal with it! I can 
get on to developing my applications.


Or the really cool Service Engine that lets me write reusable code. 
Java or otherwise!


Or all the framework tools that have been integrated and proven. 
Everything from Internationalization and localization support to XML 
document handling. (Personally, I'm tired of having to integrate XML 
parsers every time I need that functionality in an application.)


How hard is it to list some of these features? Take the "high road".

Ruth



Jacopo Cappellato wrote:

On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:


Hey come on Jacopo - overall I'm actually trying to promote the use 
of ofbiz.  I've invested a considerable amount of time in it.


I was hoping that my question would get ofbiz supporters to list 
some of the benefits of ofbiz over grails.





Eh eh... this time your attempt will not help you to get easy 
information (at least from me): you will have to do your own 
research :-)


Jacopo




Jacopo Cappellato wrote:


On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:


I can't think of anything other than this that the ofbiz 
framework provides that grails doesn't.



If you are blind, all you can see is darkness.

Jacopo

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Jacques Le Roux]

I hope to get some time to get this more clear one day...

Jacques

From: "Ruth Hoffman" 

Please, keep these coming! I certainly could use a refresher.
Ruth

Jacques Le Roux wrote:
And one of the most important thing but not obvious in OFBiz,  
extension and reutilisation of artifacts.
From hot-deploy, you can build your own applicaiton based on the 
trunk (or release but I'd recommend trunk for easier update later) 
without touching much of OFBiz itself. If you handle it right you may 
end with a couple of small patches. There are even small tools around, 
see ant - p, to deal with hat. This is where is the real OFBiz 
expertise, it takes some time to understand and use...
Also OFBiz is *great* when it comes to *not* compile, reboot, compile, 
reboot, compile, reboot, compile, reboot, compile, reboot, compile, 
reboot, OK you see...


Jacques

From: "Ruth Hoffman" 



Hi Jacopo:

IMO, one should always give positive affirmations when responding to 
posts like these. OFBiz has plenty of great things we can say that 
shouldn't require much effort on your part to comment on:


How about the seamless and transparent database support by way of the 
Entity Engine?  If you want to develop an application or implement 
ERP, then you don't need to worry about the database. You don't need 
to stress over whether to use Hiberanate or JDO or native SQL or 
whatever the latest database technology fad happens to be. The EE is 
here, its proven and best of all I don't have to deal with it! I can 
get on to developing my applications.


Or the really cool Service Engine that lets me write reusable code. 
Java or otherwise!


Or all the framework tools that have been integrated and proven. 
Everything from Internationalization and localization support to XML 
document handling. (Personally, I'm tired of having to integrate XML 
parsers every time I need that functionality in an application.)


How hard is it to list some of these features? Take the "high road".

Ruth



Jacopo Cappellato wrote:

On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:


Hey come on Jacopo - overall I'm actually trying to promote the use 
of ofbiz.  I've invested a considerable amount of time in it.


I was hoping that my question would get ofbiz supporters to list 
some of the benefits of ofbiz over grails.





Eh eh... this time your attempt will not help you to get easy 
information (at least from me): you will have to do your own 
research :-)


Jacopo




Jacopo Cappellato wrote:


On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:


I can't think of anything other than this that the ofbiz 
framework provides that grails doesn't.



If you are blind, all you can see is darkness.

Jacopo

Re: Support of german locale

[Patrick]

Hi Sebi,
I'm formatting my dates with code like this
description="${bsh:openDate.tostring().substring(5,7)}"

Maybe you will find it helpful.  Good luck
patrick

On Fri, Feb 26, 2010 at 1:31 AM, Sebi  wrote:
>
> Hi,
>
> I am new at "ofbiz" and evaluating the framework.
>
> I wonder if it is possible for users to type in a german date-format. It
> still looks like this:
>
> http://n4.nabble.com/file/n1570247/Birthdate.png
>
> I surely changed the preferences to locale "de_DE" - I also started the
> ofBiz-server under a german locale.
>
> The (label-)output of date/times is often not formattet:
>
> http://n4.nabble.com/file/n1570247/updated.png
>
> what can be done by
>
>    ${partyContactMech.fromDate?date?string.short}
>
> insted of
>
>    ${partyContactMech.fromDate}
>
> But I found no way to manage dates in inputfields in a similar way.
>
> Thank you for your help, I hope my english is ok so far...
> Sebi
> --
> View this message in context: 
> http://n4.nabble.com/Support-of-german-locale-tp1570247p1570247.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Christopher Snow]

Hi Jacques,

Thanks for the comments.

Not sure how grails handles extension of artifacts (except that 
Controllers and Services are classes so theoretically could be extended).


Grails only needs to be restarted when the hibernate definitions have 
changed (I think). Controller and Service changes are dynamically 
reloaded in development mode without a restart.


Grails has:  |"grails create-app helloworld" which is the equivalent of 
creating an ofbiz component.


In ofbiz, I always have to jump into the ofbiz code, even if its just to 
configure it (e.g. data sources).  In grails, the component 
configuration is done in the component itself.  I would never expect you 
to modify the core grails code and create patches to ship with your 
application - this is a big disadvantage with ofbiz.


Please don't think I'm giving ofbiz a hard time.  Don't forget, I'm 
interested in creating a standalone ofbiz framework (which would be 
especially useful for my current government client), but I'm not sure 
that the framework on it's own carrys any benefits compared to grails.  
It's the business applications that give ofbiz the most advantage.


Cheers,

Chris
|

Jacques Le Roux wrote:
And one of the most important thing but not obvious in OFBiz,  
extension and reutilisation of artifacts.
From hot-deploy, you can build your own applicaiton based on the trunk 
(or release but I'd recommend trunk for easier update later) without 
touching much of OFBiz itself. If you handle it right you may end with 
a couple of small patches. There are even small tools around, see ant 
- p, to deal with hat. This is where is the real OFBiz expertise, it 
takes some time to understand and use...
Also OFBiz is *great* when it comes to *not* compile, reboot, compile, 
reboot, compile, reboot, compile, reboot, compile, reboot, compile, 
reboot, OK you see...


Jacques

From: "Ruth Hoffman" 



Hi Jacopo:

IMO, one should always give positive affirmations when responding to 
posts like these. OFBiz has plenty of great things we can say that 
shouldn't require much effort on your part to comment on:


How about the seamless and transparent database support by way of the 
Entity Engine?  If you want to develop an application or implement 
ERP, then you don't need to worry about the database. You don't need 
to stress over whether to use Hiberanate or JDO or native SQL or 
whatever the latest database technology fad happens to be. The EE is 
here, its proven and best of all I don't have to deal with it! I can 
get on to developing my applications.


Or the really cool Service Engine that lets me write reusable code. 
Java or otherwise!


Or all the framework tools that have been integrated and proven. 
Everything from Internationalization and localization support to XML 
document handling. (Personally, I'm tired of having to integrate XML 
parsers every time I need that functionality in an application.)


How hard is it to list some of these features? Take the "high road".

Ruth



Jacopo Cappellato wrote:

On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:


Hey come on Jacopo - overall I'm actually trying to promote the use 
of ofbiz.  I've invested a considerable amount of time in it.


I was hoping that my question would get ofbiz supporters to list 
some of the benefits of ofbiz over grails.





Eh eh... this time your attempt will not help you to get easy 
information (at least from me): you will have to do your own 
research :-)


Jacopo




Jacopo Cappellato wrote:


On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:


I can't think of anything other than this that the ofbiz 
framework provides that grails doesn't.



If you are blind, all you can see is darkness.

Jacopo

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Ruth Hoffman]

Please, keep these coming! I certainly could use a refresher.
Ruth

Jacques Le Roux wrote:
And one of the most important thing but not obvious in OFBiz,  
extension and reutilisation of artifacts.
From hot-deploy, you can build your own applicaiton based on the 
trunk (or release but I'd recommend trunk for easier update later) 
without touching much of OFBiz itself. If you handle it right you may 
end with a couple of small patches. There are even small tools around, 
see ant - p, to deal with hat. This is where is the real OFBiz 
expertise, it takes some time to understand and use...
Also OFBiz is *great* when it comes to *not* compile, reboot, compile, 
reboot, compile, reboot, compile, reboot, compile, reboot, compile, 
reboot, OK you see...


Jacques

From: "Ruth Hoffman" 



Hi Jacopo:

IMO, one should always give positive affirmations when responding to 
posts like these. OFBiz has plenty of great things we can say that 
shouldn't require much effort on your part to comment on:


How about the seamless and transparent database support by way of the 
Entity Engine?  If you want to develop an application or implement 
ERP, then you don't need to worry about the database. You don't need 
to stress over whether to use Hiberanate or JDO or native SQL or 
whatever the latest database technology fad happens to be. The EE is 
here, its proven and best of all I don't have to deal with it! I can 
get on to developing my applications.


Or the really cool Service Engine that lets me write reusable code. 
Java or otherwise!


Or all the framework tools that have been integrated and proven. 
Everything from Internationalization and localization support to XML 
document handling. (Personally, I'm tired of having to integrate XML 
parsers every time I need that functionality in an application.)


How hard is it to list some of these features? Take the "high road".

Ruth



Jacopo Cappellato wrote:

On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:


Hey come on Jacopo - overall I'm actually trying to promote the use 
of ofbiz.  I've invested a considerable amount of time in it.


I was hoping that my question would get ofbiz supporters to list 
some of the benefits of ofbiz over grails.





Eh eh... this time your attempt will not help you to get easy 
information (at least from me): you will have to do your own 
research :-)


Jacopo




Jacopo Cappellato wrote:


On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:


I can't think of anything other than this that the ofbiz 
framework provides that grails doesn't.



If you are blind, all you can see is darkness.

Jacopo

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Jacques Le Roux]

And one of the most important thing but not obvious in OFBiz,  extension and 
reutilisation of artifacts.
From hot-deploy, you can build your own applicaiton based on the trunk (or release but I'd recommend trunk for easier update later) 
without touching much of OFBiz itself. If you handle it right you may end with a couple of small patches. There are even small tools 
around, see ant - p, to deal with hat. This is where is the real OFBiz expertise, it takes some time to understand and use...
Also OFBiz is *great* when it comes to *not* compile, reboot, compile, reboot, compile, reboot, compile, reboot, compile, reboot, 
compile, reboot, OK you see...


Jacques

From: "Ruth Hoffman" 



Hi Jacopo:

IMO, one should always give positive affirmations when responding to posts like these. OFBiz has plenty of great things we can say 
that shouldn't require much effort on your part to comment on:


How about the seamless and transparent database support by way of the Entity Engine?  If you want to develop an application or 
implement ERP, then you don't need to worry about the database. You don't need to stress over whether to use Hiberanate or JDO or 
native SQL or whatever the latest database technology fad happens to be. The EE is here, its proven and best of all I don't have 
to deal with it! I can get on to developing my applications.


Or the really cool Service Engine that lets me write reusable code. Java or 
otherwise!

Or all the framework tools that have been integrated and proven. Everything from Internationalization and localization support to 
XML document handling. (Personally, I'm tired of having to integrate XML parsers every time I need that functionality in an 
application.)


How hard is it to list some of these features? Take the "high road".

Ruth



Jacopo Cappellato wrote:

On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:


Hey come on Jacopo - overall I'm actually trying to promote the use of ofbiz.  I've invested a considerable amount of time in 
it.


I was hoping that my question would get ofbiz supporters to list some of the 
benefits of ofbiz over grails.




Eh eh... this time your attempt will not help you to get easy information (at least from me): you will have to do your own 
research :-)


Jacopo




Jacopo Cappellato wrote:


On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:



I can't think of anything other than this that the ofbiz framework provides 
that grails doesn't.


If you are blind, all you can see is darkness.

Jacopo

Re: Now Practice Application will also teach you, how to write ajax request using prototype library in OFBiz

[Vivek Mishra]

+1.

Thanks!
-- Vivek Mishra

Jacques Le Roux wrote:

Thanks Divesh, Arun and Rishi,

This will be much appreciated by everybody I'm sure

Jacques

From: "Divesh Dutta" 

Hello Users,

I have introduced  new section in Practice application of OFBiz , 
which is all about "How to write Ajax request".  By following this  a 
newbie can learn  writing ajax request and enabling client side 
validation by using prototype library.


All above stuffs  are available in newly introduced "part-6" of 
practice application in following link: 
http://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide 



I would like to thanks Arun Patidar for support and Rishi Solanki for 
idea of introducing this section.


Thanks
--
Divesh Dutta.

temporal expression

[Christopher Snow]

Hi Forum/Adrian!

We are about to make heavy use of temporal expressions on trunk.  Before 
we do, would you consider them stable at the moment?


Many thanks,

Chris

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Ruth Hoffman]

Hi Jacopo:

IMO, one should always give positive affirmations when responding to 
posts like these. OFBiz has plenty of great things we can say that 
shouldn't require much effort on your part to comment on:


How about the seamless and transparent database support by way of the 
Entity Engine?  If you want to develop an application or implement ERP, 
then you don't need to worry about the database. You don't need to 
stress over whether to use Hiberanate or JDO or native SQL or whatever 
the latest database technology fad happens to be. The EE is here, its 
proven and best of all I don't have to deal with it! I can get on to 
developing my applications.


Or the really cool Service Engine that lets me write reusable code. Java 
or otherwise!


Or all the framework tools that have been integrated and proven. 
Everything from Internationalization and localization support to XML 
document handling. (Personally, I'm tired of having to integrate XML 
parsers every time I need that functionality in an application.)


How hard is it to list some of these features? Take the "high road".

Ruth



Jacopo Cappellato wrote:

On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:

  

Hey come on Jacopo - overall I'm actually trying to promote the use of ofbiz.  
I've invested a considerable amount of time in it.

I was hoping that my question would get ofbiz supporters to list some of the 
benefits of ofbiz over grails.




Eh eh... this time your attempt will not help you to get easy information (at 
least from me): you will have to do your own research :-)

Jacopo


  

Jacopo Cappellato wrote:


On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:

 
  

I can't think of anything other than this that the ofbiz framework provides 
that grails doesn't.
 
  

If you are blind, all you can see is darkness.

Jacopo

 
  



  

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Christopher Snow]

I'm not looking for easy information. Based on my experience of ofbiz 
and grails - I really don't know what else ofbiz brings to the table.


I was hoping that I'd missed something fairly obvious which is why I 
threw the question out to the list.


Jacopo Cappellato wrote:

On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:

  

Hey come on Jacopo - overall I'm actually trying to promote the use of ofbiz.  
I've invested a considerable amount of time in it.

I was hoping that my question would get ofbiz supporters to list some of the 
benefits of ofbiz over grails.




Eh eh... this time your attempt will not help you to get easy information (at 
least from me): you will have to do your own research :-)

Jacopo


  

Jacopo Cappellato wrote:


On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:

 
  

I can't think of anything other than this that the ofbiz framework provides 
that grails doesn't.
 
  

If you are blind, all you can see is darkness.

Jacopo

 
  


  

Re: How do we assign Tracking Code to Promotion and track them?

[Scott Gray]

One person on the mailing list maybe wants to read that bumped message, but 
instead it is being sent to hundreds of subscribers who then have to deal with 
a message of no value to them.  Messages are also typically bumped because they 
are waiting for a reply, this causes confusion and more time spent looking at 
an irrelevant message.  So it may be more work on your part to do as I ask, but 
perhaps it will be less work for everyone else.

Thanks
Scott

On 26/02/2010, at 2:00 AM, BJ Freeman wrote:

> more work on my part since I search the mail history in my email
> history. Is there a reason I am missing.
> 
> Scott Gray sent the following on 2/25/2010 10:44 PM:
>> Please don't do this, if you want to point someone to an old thread just 
>> link to the threads in nabble or markmail.
>> 
>> Thanks
>> Scott
>> 
>> HotWax Media
>> http://www.hotwaxmedia.com
>> 
>> On 25/02/2010, at 3:12 AM, BJ Freeman wrote:
>> 
>>> bump this up to explain tracking codes in ofbiz
>>> 
>>> Jacques Le Roux sent the following on 2/17/2008 1:01 AM:
 Simply assign the Promotion Code you want to track to the Tracking Code
 Id field when creating a new Tracking Code
 
 You might be interested by
 http://docs.ofbiz.org/download/attachments/742/ManagerReferenceMarketing.pdf?version=1
 p. 24 §.4.5.3.
 Excerpt : <>>> ID. If this same code is needed by the customer to
 qualify for a promotion, make it easy for them to use.>>
 
 Jacques
 
 From: "Ajey" 
> Hi all,
> how a tracking code can be applied to a particular promotion and how
> we can
> track the usage of a particular Promotion with this Tracking Code. Please
> help me out. thanx
> -- 
> View this message in context:
> http://www.nabble.com/How-do-we-assign-Tracking-Code-to-Promotion-and-track-them--tp15477314p15477314.html
> 
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 
 
 
 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Jacopo Cappellato]

On Feb 26, 2010, at 2:27 PM, Christopher Snow wrote:

> Hey come on Jacopo - overall I'm actually trying to promote the use of ofbiz. 
>  I've invested a considerable amount of time in it.
> 
> I was hoping that my question would get ofbiz supporters to list some of the 
> benefits of ofbiz over grails.
> 

Eh eh... this time your attempt will not help you to get easy information (at 
least from me): you will have to do your own research :-)

Jacopo


> Jacopo Cappellato wrote:
>> On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:
>> 
>>  
 I can't think of anything other than this that the ofbiz framework 
 provides that grails doesn't.
  
>> 
>> If you are blind, all you can see is darkness.
>> 
>> Jacopo
>> 
>>  
> 

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Christopher Snow]

Hey come on Jacopo - overall I'm actually trying to promote the use of 
ofbiz.  I've invested a considerable amount of time in it.


I was hoping that my question would get ofbiz supporters to list some of 
the benefits of ofbiz over grails.


Jacopo Cappellato wrote:

On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:

  

I can't think of anything other than this that the ofbiz framework provides 
that grails doesn't.
  


If you are blind, all you can see is darkness.

Jacopo

  

Re: Now Practice Application will also teach you, how to write ajax request using prototype library in OFBiz

[Jacques Le Roux]

Thanks Divesh, Arun and Rishi,

This will be much appreciated by everybody I'm sure

Jacques

From: "Divesh Dutta" 

Hello Users,

I have introduced  new section in Practice application of OFBiz , which 
is all about "How to write Ajax request".  By following this  a newbie 
can learn  writing ajax request and enabling client side validation by 
using prototype library.


All above stuffs  are available in newly introduced "part-6" of practice 
application in following link: 
http://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide


I would like to thanks Arun Patidar for support and Rishi Solanki for 
idea of introducing this section.


Thanks
--
Divesh Dutta.

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Jacopo Cappellato]

On Feb 26, 2010, at 1:20 PM, Christopher Snow wrote:

>> I can't think of anything other than this that the ofbiz framework provides 
>> that grails doesn't.
> 

If you are blind, all you can see is darkness.

Jacopo

Re: Now Practice Application will also teach you, how to write ajax request using prototype library in OFBiz

[Rishi Solanki]

Great Effort !
Thanks Divesh for doing this, glad to see the enhanced practice application.

Rishi Solanki
Enterprise Software Developer
HotWax Media Pvt. Ltd.


On Fri, Feb 26, 2010 at 4:26 PM, Divesh Dutta
wrote:

> Hello Users,
>
> I have introduced  new section in Practice application of OFBiz , which is
> all about "How to write Ajax request".  By following this  a newbie can
> learn  writing ajax request and enabling client side validation by using
> prototype library.
>
> All above stuffs  are available in newly introduced "part-6" of practice
> application in following link:
> http://cwiki.apache.org/confluence/display/leftOFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide
>
> I would like to thanks Arun Patidar for support and Rishi Solanki for idea
> of introducing this section.
>
> Thanks
> --
> Divesh Dutta.
>
>

Re: Now Practice Application will also teach you, how to write ajax request using prototype library in OFBiz

[Christopher Snow]

That's fantastic news - learning the ofbiz ajax implementation has been 
on my list for a while.  Thanks for making my life easier!


Divesh Dutta wrote:

Hello Users,

I have introduced  new section in Practice application of OFBiz , 
which is all about "How to write Ajax request".  By following this  a 
newbie can learn  writing ajax request and enabling client side 
validation by using prototype library.


All above stuffs  are available in newly introduced "part-6" of 
practice application in following link: 
http://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide 



I would like to thanks Arun Patidar for support and Rishi Solanki for 
idea of introducing this section.


Thanks
--
Divesh Dutta.

Re: Now Practice Application will also teach you, how to write ajax request using prototype library in OFBiz

[Ashish Vijaywargiya]

Thanks Guys. I appreciate your help in arranging this section for the 
community members.


--
Regards
Ashish Vijaywargiya
http://www.saveourtigers.com/

Divesh Dutta wrote:

Hello Users,

I have introduced  new section in Practice application of OFBiz , 
which is all about "How to write Ajax request".  By following this  a 
newbie can learn  writing ajax request and enabling client side 
validation by using prototype library.


All above stuffs  are available in newly introduced "part-6" of 
practice application in following link: 
http://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide 



I would like to thanks Arun Patidar for support and Rishi Solanki for 
idea of introducing this section.


Thanks
--
Divesh Dutta.



smime.p7s
Description: S/MIME Cryptographic Signature

Now Practice Application will also teach you, how to write ajax request using prototype library in OFBiz

[Divesh Dutta]

Hello Users,

I have introduced  new section in Practice application of OFBiz , which 
is all about "How to write Ajax request".  By following this  a newbie 
can learn  writing ajax request and enabling client side validation by 
using prototype library.


All above stuffs  are available in newly introduced "part-6" of practice 
application in following link: 
http://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Tutorial+-+A+Beginners+Development+Guide


I would like to thanks Arun Patidar for support and Rishi Solanki for 
idea of introducing this section.


Thanks
--
Divesh Dutta.

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Christopher Snow]

One more - inline...

Christopher Snow wrote:

Hi Miles,

I'm currently doing some work on making a standalone ofbiz development 
framework (i.e. no business functionality).  Your questions have got 
me thinking:


  "what does the ofbiz framework give you that the grails framework 
doesn't?"


A possible answer:

  "Ofbiz gives you a ready made layout for backend management UI (i.e. 
screens, menus, forms)"
the ofbiz framework will give you an easy upgrade path to the full ofbiz 
and all its business functionality.


I can't think of anything other than this that the ofbiz framework 
provides that grails doesn't.


Cheers,

Chris


Miles Huang wrote:

Hi OFBIZ users and developers,

  First of all, I'm a novice of OFBIZ. I've just started to learn and 
use it
for a couple of month. So if I have made some mistake in the 
following post,

criticisms are welcomed :clap:

  Does anyone using OFBIZ interested in porting OFBIZ to leverage a 
mature

and decent web platform, more specifically Grails?

  The idea comes from the post from Christopher Snow, "There was some
interest in porting openerp to jython", and the recent hot topic "groovy
service code instead of minilang". Excuse me, I'm going a step 
further.:-P


  The problem an OFBIZ novice commonly facing is when he/she has to go
further than the OFBIZ OOTB functionality ( which proves he/she is 
becoming
a really OFBIZ user:drunk: ). He/she have to learn a lot of 
techniques in

the unique OFBIZ way, which is commonly a well defined web
framework/OR-mapping tool should take care. This make learning-curve 
steep.
I fully understand the historical reason of OBFIZ, such as OFBIZ 
utilize the

IoC idea earlier than Spring, entity-engine evolution over EJB2, and the
ability to avoid the compile-deploy-test cycle and make development more
efficient. And I really admire them, especially considering the age when
OFBIZ developers invent them. But these are not unique features of 
OFBIZ now
a days. Leading web development platforms such as RoR and Grails has 
go much
further than what OFBIZ's technical platform can provide, since they 
have

dedicated man power to spend in researching these area.

  What make things worse is many ways to accomplish same goal in 
OFBIZ. xml
mini-lang, groovy, bsh, java, just named some. It giving developers 
freedom

to choose technology what they like, sounds good. But it is a different
story for the long term platform maintainers and customizers. With 
adequate
open practice, can we gain enough experience to concentrate on a 
consistent
way to do development task in OFBIZ? (To make me clear, I'm not 
advocating a

single programming language to solve any problem).

  So..., why I'm still interested in OFBIZ? I must admit even with the
complains, I'm still an OFBIZ fans till now. The answer is the business
level functionalities. This is the real strength of OFBIZ.

  Since most services and actions have implemented in groovy/Java, 
porting

these code to Grails are smooth. With the leverage of Groovy DSL over
mini-lang, we will go further. Theoretically the chance to migrate 
the whole
OFBIZ package to Grails platform are possible (more serious research 
work
needs to be done in this area), while keeping the strength of OFBIZ - 
the

business level assets accumulated in years.

  Of course it will not be an easy step, only great gains worth such 
huge

change. So what we may gain from the transition:
* Faster development speed - more efficient, on-rails level;
* Less code - less maintenance spend;
* More concentrate - No more re-invent wheel. Let's concentrate on what
makes OFBIZ unique and leading-edge in limited resource;
* More 3rd party software integration ability - provided by the Grails
platform and plenty of plugins;
* Easier deployment - no more embedding Tomcat, just standard war 
packages,

which is deployable to any container, even cloud computing providers;
* Last but not least, more smooth learning curve - the key factor to 
gain

more new coming user and make success.

  Is this a right way to the future? Any thoughts?

Regards,
Miles.
  

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Christopher Snow]

Hi Miles,

I'm currently doing some work on making a standalone ofbiz development 
framework (i.e. no business functionality).  Your questions have got me 
thinking:


  "what does the ofbiz framework give you that the grails framework 
doesn't?"


A possible answer:

  "Ofbiz gives you a ready made layout for backend management UI (i.e. 
screens, menus, forms)"


I can't think of anything other than this that the ofbiz framework 
provides that grails doesn't.


Cheers,

Chris


Miles Huang wrote:

Hi OFBIZ users and developers,

  First of all, I'm a novice of OFBIZ. I've just started to learn and use it
for a couple of month. So if I have made some mistake in the following post,
criticisms are welcomed :clap:

  Does anyone using OFBIZ interested in porting OFBIZ to leverage a mature
and decent web platform, more specifically Grails?

  The idea comes from the post from Christopher Snow, "There was some
interest in porting openerp to jython", and the recent hot topic "groovy
service code instead of minilang". Excuse me, I'm going a step further.:-P

  The problem an OFBIZ novice commonly facing is when he/she has to go
further than the OFBIZ OOTB functionality ( which proves he/she is becoming
a really OFBIZ user:drunk: ). He/she have to learn a lot of techniques in
the unique OFBIZ way, which is commonly a well defined web
framework/OR-mapping tool should take care. This make learning-curve steep.
I fully understand the historical reason of OBFIZ, such as OFBIZ utilize the
IoC idea earlier than Spring, entity-engine evolution over EJB2, and the
ability to avoid the compile-deploy-test cycle and make development more
efficient. And I really admire them, especially considering the age when
OFBIZ developers invent them. But these are not unique features of OFBIZ now
a days. Leading web development platforms such as RoR and Grails has go much
further than what OFBIZ's technical platform can provide, since they have
dedicated man power to spend in researching these area.

  What make things worse is many ways to accomplish same goal in OFBIZ. xml
mini-lang, groovy, bsh, java, just named some. It giving developers freedom
to choose technology what they like, sounds good. But it is a different
story for the long term platform maintainers and customizers. With adequate
open practice, can we gain enough experience to concentrate on a consistent
way to do development task in OFBIZ? (To make me clear, I'm not advocating a
single programming language to solve any problem).

  So..., why I'm still interested in OFBIZ? I must admit even with the
complains, I'm still an OFBIZ fans till now. The answer is the business
level functionalities. This is the real strength of OFBIZ.

  Since most services and actions have implemented in groovy/Java, porting
these code to Grails are smooth. With the leverage of Groovy DSL over
mini-lang, we will go further. Theoretically the chance to migrate the whole
OFBIZ package to Grails platform are possible (more serious research work
needs to be done in this area), while keeping the strength of OFBIZ - the
business level assets accumulated in years.

  Of course it will not be an easy step, only great gains worth such huge
change. So what we may gain from the transition:
* Faster development speed - more efficient, on-rails level;
* Less code - less maintenance spend;
* More concentrate - No more re-invent wheel. Let's concentrate on what
makes OFBIZ unique and leading-edge in limited resource;
* More 3rd party software integration ability - provided by the Grails
platform and plenty of plugins;
* Easier deployment - no more embedding Tomcat, just standard war packages,
which is deployable to any container, even cloud computing providers;
* Last but not least, more smooth learning curve - the key factor to gain
more new coming user and make success.

  Is this a right way to the future? Any thoughts?

Regards,
Miles.
  

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Sascha Rodekamp]

Hi Miles,
i really like to see a POC of an Grails OFBiz component.

I think this could be an interesting project.
So Miles keep on working :-)

2010/2/26 huang.mi...@gmail.com 

> On Fri, 2010-02-26 at 10:06 +0100, Jacques Le Roux wrote:
> > Miles,
> >
> > Well tried, from your argumentation I guess that
> >
> > 1) you certainly know Grail,
> > 2) most of us don't,
> I don't think most of you don't. Grails development is merely writing
> Groovy code, with which most of you are familiar already. What make
> Grails source code difference is many DSL extension specifically to
> solve common WEB application requirements. Again you are also familiar
> with DSL concept already, the mini-lang could be considered as a DSL
> based on XML. Grails use Groovy DSL to gain similar high programming
> efficiency.
>
> > 3) you don't know much about OFBiz yet
> >
> > So you try to push Grail and we brake on it. As David wisely suggested in
> another email a POC is the way for you now...
> >
> > Thanks for you interest in OFBiz
> >
> > Jacques
>
>   Nice summary. I agree a POC will make things clear. A sample Grails
> OFBIZ component would be a better discussion base.
>
>  Now I've heard the voice from the community and it's time to do more
> research on the subject and learn more on OFBIZ itself. Hope I can work
> out a sample component in Grails recently.
>
> Thanks,
> Miles.
>
>
>


-- 
http://www.lynx.de

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[huang.mi...@gmail.com]

On Fri, 2010-02-26 at 10:06 +0100, Jacques Le Roux wrote:
> Miles,
> 
> Well tried, from your argumentation I guess that 
> 
> 1) you certainly know Grail, 
> 2) most of us don't, 
I don't think most of you don't. Grails development is merely writing
Groovy code, with which most of you are familiar already. What make
Grails source code difference is many DSL extension specifically to
solve common WEB application requirements. Again you are also familiar
with DSL concept already, the mini-lang could be considered as a DSL
based on XML. Grails use Groovy DSL to gain similar high programming
efficiency.

> 3) you don't know much about OFBiz yet
> 
> So you try to push Grail and we brake on it. As David wisely suggested in 
> another email a POC is the way for you now...
> 
> Thanks for you interest in OFBiz
> 
> Jacques

  Nice summary. I agree a POC will make things clear. A sample Grails
OFBIZ component would be a better discussion base.

  Now I've heard the voice from the community and it's time to do more
research on the subject and learn more on OFBIZ itself. Hope I can work
out a sample component in Grails recently.

Thanks,
Miles.

Re: How do we assign Tracking Code to Promotion and track them?

[Jacques Le Roux]

For search on OFBiz MLs I use 4 tools  (I'm on Windows and - still :/ - use 
Outlook Express).
1) In Outlook Express folders (convenient in some cases when you know you are near the target, for instance a recent svn number, may 
be too long otherwise)

2) MarkMail often the quicker but you have to be acquainted with it
3) Nabble seems to be quicker now that we have switched to new version, in the meantime I got used to MarkMail. It has something 
that MarkMail does nof offer(?) separated forums (ie dev vs user, etc.)
4) Copernic desktop (for old - not eve in Nabble, though I have it only from Sept. 04 - or wide searches, ie when I don't find with 
other tools). I only index emails, else it'd be a nightmare I guess (Windows files system)


The FF plugins tools help you with MarkMail and Nabble

HTH

Jacques

From: "BJ Freeman" 

more work on my part since I search the mail history in my email
history. Is there a reason I am missing.

Scott Gray sent the following on 2/25/2010 10:44 PM:

Please don't do this, if you want to point someone to an old thread just link 
to the threads in nabble or markmail.

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

On 25/02/2010, at 3:12 AM, BJ Freeman wrote:


bump this up to explain tracking codes in ofbiz

Jacques Le Roux sent the following on 2/17/2008 1:01 AM:

Simply assign the Promotion Code you want to track to the Tracking Code
Id field when creating a new Tracking Code

You might be interested by
http://docs.ofbiz.org/download/attachments/742/ManagerReferenceMarketing.pdf?version=1
p. 24 §.4.5.3.
Excerpt : <>

Jacques

From: "Ajey" 

Hi all,
how a tracking code can be applied to a particular promotion and how
we can
track the usage of a particular Promotion with this Tracking Code. Please
help me out. thanx
--
View this message in context:
http://www.nabble.com/How-do-we-assign-Tracking-Code-to-Promotion-and-track-them--tp15477314p15477314.html

Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Brain-storm: OFBIZ on Grails, is this a right way for the future?

[Jacques Le Roux]

Miles,

Well tried, from your argumentation I guess that 

1) you certainly know Grail, 
2) most of us don't, 
3) you don't know much about OFBiz yet


So you try to push Grail and we brake on it. As David wisely suggested in 
another email a POC is the way for you now...

Thanks for you interest in OFBiz

Jacques

From: 

Just list some of the gains by different roles involved in the OFBIZ
ecosystem:

* For OFBIZ provider business owners and end-users:
As such a sophisticated business application, the training cost for new
comers is much high. The cost can be branched into 2 parts:
1) Learning the business model and logic implemented by OFBIZ
2) Learning OFBIZ's unique technical platform
The first part cost is no doubt value-able and unavoidable, because it's
closely related to the business and specific product.
But the second part is the cost that doesn't gain any direct benefits to
the business. So they like to find a way to cut down such cost. To find
a new developer familiar with Grails is much easier than find a new
developer familiar with OFBIZ platform, isn't it? The second part cost
can be cut down to 0 by hire a qualified developer.

* For NEW developers:
Assume the worst case, the new developers doesn't familiar either of
these technologies. Then he has 2 choices:
1) Spend 2 months to get familiar with the unique OFBIZ technical
platform, which may get the OFBIZ job done, but nothing else.
2) Spend 2 months to learn a technology like Grails, which can not only
solve the OFBIZ related requirements, but also suitable to solve a
wide-range of web development problems.
Which one do you think he/she would like to spend their time into?

* For current Experts:
They may need to learn a new technologies, but this is one-time cost.
After this, they can be released from the long-last technical platform
maintain task, concentrate on the core business issues.
Although I don't know them yet, I bet the maintainers of the OFBIZ
technical platform may have gathered a lot of improvement idea for the
core platform already, inspired by other leading platforms. But they
have limited time/effort to do so, or even just wondering: does it
worthwhile to re-invent the wheels?

-Miles


On Wed, 2010-02-24 at 13:03 -0800, Adrian Crum wrote:

Miles Huang wrote:
>   The problem an OFBIZ novice commonly facing is when he/she has to go
> further than the OFBIZ OOTB functionality ( which proves he/she is becoming
> a really OFBIZ user:drunk: ). He/she have to learn a lot of techniques in
> the unique OFBIZ way

> Theoretically the chance to migrate the whole
> OFBIZ package to Grails platform are possible (more serious research work
> needs to be done in this area), while keeping the strength of OFBIZ - the
> business level assets accumulated in years.

So we trade new users having to learn the OFBiz way for new users having 
to learn the Grails way. What have we gained?


-Adrian

Re: How do we assign Tracking Code to Promotion and track them?

[BJ Freeman]

more work on my part since I search the mail history in my email
history. Is there a reason I am missing.

Scott Gray sent the following on 2/25/2010 10:44 PM:
> Please don't do this, if you want to point someone to an old thread just link 
> to the threads in nabble or markmail.
> 
> Thanks
> Scott
> 
> HotWax Media
> http://www.hotwaxmedia.com
> 
> On 25/02/2010, at 3:12 AM, BJ Freeman wrote:
> 
>> bump this up to explain tracking codes in ofbiz
>>
>> Jacques Le Roux sent the following on 2/17/2008 1:01 AM:
>>> Simply assign the Promotion Code you want to track to the Tracking Code
>>> Id field when creating a new Tracking Code
>>>
>>> You might be interested by
>>> http://docs.ofbiz.org/download/attachments/742/ManagerReferenceMarketing.pdf?version=1
>>> p. 24 §.4.5.3.
>>> Excerpt : <>> ID. If this same code is needed by the customer to
>>> qualify for a promotion, make it easy for them to use.>>
>>>
>>> Jacques
>>>
>>> From: "Ajey" 
 Hi all,
 how a tracking code can be applied to a particular promotion and how
 we can
 track the usage of a particular Promotion with this Tracking Code. Please
 help me out. thanx
 -- 
 View this message in context:
 http://www.nabble.com/How-do-we-assign-Tracking-Code-to-Promotion-and-track-them--tp15477314p15477314.html

 Sent from the OFBiz - User mailing list archive at Nabble.com.

>>>
>>>
>>>
> 

Re: How do we assign Tracking Code to Promotion and track them?

[Jacques Le Roux]

Yes, I agree, I found that weird too. There are good tools available (plugins if you use Firefox) for research at 
http://cwiki.apache.org/confluence/x/igBk


Jacques

From: "Scott Gray" 
Please don't do this, if you want to point someone to an old thread just link 
to the threads in nabble or markmail.

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

On 25/02/2010, at 3:12 AM, BJ Freeman wrote:


bump this up to explain tracking codes in ofbiz

Jacques Le Roux sent the following on 2/17/2008 1:01 AM:

Simply assign the Promotion Code you want to track to the Tracking Code
Id field when creating a new Tracking Code

You might be interested by
http://docs.ofbiz.org/download/attachments/742/ManagerReferenceMarketing.pdf?version=1
p. 24 §.4.5.3.
Excerpt : <>

Jacques

From: "Ajey" 


Hi all,
how a tracking code can be applied to a particular promotion and how
we can
track the usage of a particular Promotion with this Tracking Code. Please
help me out. thanx
--
View this message in context:
http://www.nabble.com/How-do-we-assign-Tracking-Code-to-Promotion-and-track-them--tp15477314p15477314.html

Sent from the OFBiz - User mailing list archive at Nabble.com.