You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Skip <sk...@thedevers.org> on 2016/08/05 17:55:12 UTC
Ofbiz Cookbook
I just got finished reading Apache OFBiz Cookbook (Open Source: Community
Experience Distilled) by Ruth Hoffman.
I have been writing Ofbiz code since before it was an Apache project. This
book would have saved me six months of digging through Ofbiz code and
inspite of my nearly a decade of experience, I still learned several new
things in it.
I highly recommend this book to everyone, beginner and expert alike and
strongly recommend this book for anyone just getting started. It is well
written and worth every penny. When you get the Data Resource book, get
this one too and read it first.
Amazon has it here
https://www.amazon.com/gp/product/1847199186/ref=oh_aui_detailpage_o05_s00?i
e=UTF8&psc=1
I have never met or spoken to Ruth even though she posts on this forum from
time to time.
Thanks Ruth.
Skip
Re: Ofbiz Cookbook
Posted by Pranay Pandey <pr...@hotwaxsystems.com>.
Very interesting discussion. What paul has mentioned is making perfect
sense.
Best regards,
Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/
On Tue, Aug 9, 2016 at 1:39 PM, Paul Piper <pp...@ilscipio.com> wrote:
> Skip,
>
> I fear that you may be right with regards to minilang and the community,
> though luckily with your own projects you can set your own standards. I
> learned the hard way that minilang leads to more cluttered code and though
> there are some benefits (the automapping of service maps or entity-auto for
> creating crud services), I would strongly recommend anyone to rather invest
> the time into proper java or groovy code.
>
> As for the use of widgets over ftl, perhaps it is worth noting that we
> streamlined both for Scipio ERP. They share the same underlying set of
> macros and will create the hence create the same HTML & classes as are
> defined by your theme. So if people prefer to use widgets, they can. We
> relied on this, when cleaning up & converting usable screens alot, as not
> always it would make sense to transfer them to ftl.
>
> That being said, our goal is to further replace widgets by ftl logic as we
> move along. For both minilang and widgets the reason on our end is that
> neither technology is used anywhere outside of the ofbiz project and thus
> adds to the overall learning-curve for newcomers. We much rather rely on
> trusted alternatives that are easier to pick up for our project ;)
>
> Cheers,
> Paul
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.
> com/Ofbiz-Cookbook-tp4690647p4690733.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
Re: Realistic lean Roadmap [was Ofbiz Cookbook]
Posted by Jacques Le Roux <ja...@les7arts.com>.
You are right, it should be moved to the open space. I'll wait a consensus before engaging more effort on this. Not only on the page itself but also
on the prioritized goals.
Jacques
Le 17/08/2016 � 20:01, Pierre Smits a �crit :
> Is it in the right space? Where it is now, I would say it is a fest of
> privileged contributors.
>
> Best regards,
>
> Pierre
>
> On Wednesday, August 17, 2016, Jacques Le Roux <ja...@les7arts.com>
> wrote:
>
>> Hi All,
>>
>> I move and replace the "Ofbiz Cookbook" thread from the user ML since it
>> concerns more developers
>>
>> We need to have a very realistic lean Roadmap to agree on, follow and
>> progress.
>>
>> We can reuse https://cwiki.apache.org/confluence/display/OFBADMIN/New+
>> Features+Roadmap+-+Living+Document by simply prioritize the goals, then
>> pick up them as they come and prioritize again now and then when needed.
>>
>> We don't need to prioritize all tasks. Simply few that we put at top to
>> really work on them as a team and then sort again once they are done.
>> For that I have already added in this order "Introduce a plugin system"
>> and "Replace Minilang and widgets actions by a Groovy DSL"
>>
>> Also I don't think we need to maintain lists of "interested" and "willing
>> to help" people by goal. So I have removed this information. It's about
>> having a lean roadmap here, anybody can join at any moment. Rather links to
>> Jira can help to find people interested.
>>
>> I just removed the achieved or abandoned goals there:
>> Abandoned: Ivy integration (because of Gradle integration), Complete the
>> support for VAT(WIP was removed)
>> Achieved: Solr integration
>>
>> It simple and lean, what do you think?
>>
>> Jacques
>>
>>
>> Le 13/08/2016 � 10:19, Taher Alkhateeb a �crit :
>>
>>> +1
>>>
>>> On Aug 13, 2016 10:18 AM, "gil portenseigne" <gil.portenseigne@nereide.fr
>>> wrote:
>>>
>>> Yes i like this plan :)
>>>> Gil
>>>>
>>>> Le 12/08/2016 � 13:26, Jacques Le Roux a �crit :
>>>>
>>>> Yes, and I believe, when we will have worked out Gradle stuff (at least:
>>>>> finishing it, adding plugins, correctly documenting the whole) we should
>>>>> gather to work on this and slowly replace/improve the old good Minilang
>>>>>
>>>>> Could be the R17 main task?
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 12/08/2016 � 12:34, gil portenseigne a �crit :
>>>>>
>>>>> +1
>>>>>> Indeed, and moreover in the wiki page you link, there is autocompletion
>>>>>> configuration in IDE Integration part.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Gil
>>>>>>
>>>>>>
>>>>>> Le 12/08/2016 � 12:13, Jacques Le Roux a �crit :
>>>>>>
>>>>>> +1
>>>>>>> I think Jacopo has more to say about that :)
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
>>>>>>> DSL+for+OFBiz+business+logic
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 09/08/2016 � 19:11, Taher Alkhateeb a �crit :
>>>>>>>
>>>>>>> I would like to add to what Scott already mentioned that minilang is
>>>>>>>> not
>>>>>>>> only difficult to debug but also overly verbose.
>>>>>>>>
>>>>>>>> However, minilang exists and continues to be used I think because of
>>>>>>>> the
>>>>>>>> ctrl-space auto complete combined with XSD definitions for the
>>>>>>>> statements.
>>>>>>>> This makes it a DSL (not too pretty) and this is something that we
>>>>>>>> did
>>>>>>>> not
>>>>>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>>>>>> for an
>>>>>>>> alternative DSL but we don't have something yet which is
>>>>>>>> comprehensively
>>>>>>>> documented with an easy auto-complete feature. This is very important
>>>>>>>> for
>>>>>>>> many developers I think. So we need to think of a good alternative
>>>>>>>>
>>>>>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <
>>>>>>>> scott.gray@hotwaxsystems.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I'm certainly no fan of minilang. I prefer something I can step
>>>>>>>> through
>>>>>>>>
>>>>>>>>> with a debugger.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
>>>>>>>>>
>>>>>>>>> Skip,
>>>>>>>>>
>>>>>>>>>> I fear that you may be right with regards to minilang and the
>>>>>>>>>> community,
>>>>>>>>>> though luckily with your own projects you can set your own
>>>>>>>>>> standards. I
>>>>>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>>>>>>>
>>>>>>>>>> though
>>>>>>>>> there are some benefits (the automapping of service maps or
>>>>>>>>>> entity-auto
>>>>>>>>>>
>>>>>>>>>> for
>>>>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>>>>>>> invest
>>>>>>>>> the time into proper java or groovy code.
>>>>>>>>>> As for the use of widgets over ftl, perhaps it is worth noting that
>>>>>>>>>> we
>>>>>>>>>> streamlined both for Scipio ERP. They share the same underlying set
>>>>>>>>>> of
>>>>>>>>>> macros and will create the hence create the same HTML & classes as
>>>>>>>>>> are
>>>>>>>>>> defined by your theme. So if people prefer to use widgets, they
>>>>>>>>>> can.
>>>>>>>>>> We
>>>>>>>>>> relied on this, when cleaning up & converting usable screens alot,
>>>>>>>>>> as not
>>>>>>>>>> always it would make sense to transfer them to ftl.
>>>>>>>>>>
>>>>>>>>>> That being said, our goal is to further replace widgets by ftl
>>>>>>>>>> logic
>>>>>>>>>> as
>>>>>>>>>>
>>>>>>>>>> we
>>>>>>>>> move along. For both minilang and widgets the reason on our end is
>>>>>>>>>> that
>>>>>>>>>> neither technology is used anywhere outside of the ofbiz project
>>>>>>>>>> and
>>>>>>>>>> thus
>>>>>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>>>>>> rely on
>>>>>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
Re: Realistic lean Roadmap [was Ofbiz Cookbook]
Posted by Pierre Smits <pi...@gmail.com>.
Is it in the right space? Where it is now, I would say it is a fest of
privileged contributors.
Best regards,
Pierre
On Wednesday, August 17, 2016, Jacques Le Roux <ja...@les7arts.com>
wrote:
> Hi All,
>
> I move and replace the "Ofbiz Cookbook" thread from the user ML since it
> concerns more developers
>
> We need to have a very realistic lean Roadmap to agree on, follow and
> progress.
>
> We can reuse https://cwiki.apache.org/confluence/display/OFBADMIN/New+
> Features+Roadmap+-+Living+Document by simply prioritize the goals, then
> pick up them as they come and prioritize again now and then when needed.
>
> We don't need to prioritize all tasks. Simply few that we put at top to
> really work on them as a team and then sort again once they are done.
> For that I have already added in this order "Introduce a plugin system"
> and "Replace Minilang and widgets actions by a Groovy DSL"
>
> Also I don't think we need to maintain lists of "interested" and "willing
> to help" people by goal. So I have removed this information. It's about
> having a lean roadmap here, anybody can join at any moment. Rather links to
> Jira can help to find people interested.
>
> I just removed the achieved or abandoned goals there:
> Abandoned: Ivy integration (because of Gradle integration), Complete the
> support for VAT(WIP was removed)
> Achieved: Solr integration
>
> It simple and lean, what do you think?
>
> Jacques
>
>
> Le 13/08/2016 à 10:19, Taher Alkhateeb a écrit :
>
>> +1
>>
>> On Aug 13, 2016 10:18 AM, "gil portenseigne" <gil.portenseigne@nereide.fr
>> >
>> wrote:
>>
>> Yes i like this plan :)
>>>
>>> Gil
>>>
>>> Le 12/08/2016 à 13:26, Jacques Le Roux a écrit :
>>>
>>> Yes, and I believe, when we will have worked out Gradle stuff (at least:
>>>> finishing it, adding plugins, correctly documenting the whole) we should
>>>> gather to work on this and slowly replace/improve the old good Minilang
>>>>
>>>> Could be the R17 main task?
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 12/08/2016 à 12:34, gil portenseigne a écrit :
>>>>
>>>> +1
>>>>>
>>>>> Indeed, and moreover in the wiki page you link, there is autocompletion
>>>>> configuration in IDE Integration part.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Gil
>>>>>
>>>>>
>>>>> Le 12/08/2016 à 12:13, Jacques Le Roux a écrit :
>>>>>
>>>>> +1
>>>>>>
>>>>>> I think Jacopo has more to say about that :)
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
>>>>>> DSL+for+OFBiz+business+logic
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 09/08/2016 à 19:11, Taher Alkhateeb a écrit :
>>>>>>
>>>>>> I would like to add to what Scott already mentioned that minilang is
>>>>>>> not
>>>>>>> only difficult to debug but also overly verbose.
>>>>>>>
>>>>>>> However, minilang exists and continues to be used I think because of
>>>>>>> the
>>>>>>> ctrl-space auto complete combined with XSD definitions for the
>>>>>>> statements.
>>>>>>> This makes it a DSL (not too pretty) and this is something that we
>>>>>>> did
>>>>>>> not
>>>>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>>>>> for an
>>>>>>> alternative DSL but we don't have something yet which is
>>>>>>> comprehensively
>>>>>>> documented with an easy auto-complete feature. This is very important
>>>>>>> for
>>>>>>> many developers I think. So we need to think of a good alternative
>>>>>>>
>>>>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <
>>>>>>> scott.gray@hotwaxsystems.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I'm certainly no fan of minilang. I prefer something I can step
>>>>>>> through
>>>>>>>
>>>>>>>> with a debugger.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
>>>>>>>>
>>>>>>>> Skip,
>>>>>>>>
>>>>>>>>> I fear that you may be right with regards to minilang and the
>>>>>>>>> community,
>>>>>>>>> though luckily with your own projects you can set your own
>>>>>>>>> standards. I
>>>>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>>>>>>
>>>>>>>>> though
>>>>>>>>
>>>>>>>> there are some benefits (the automapping of service maps or
>>>>>>>>> entity-auto
>>>>>>>>>
>>>>>>>>> for
>>>>>>>>
>>>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>>>>>>
>>>>>>>>> invest
>>>>>>>>
>>>>>>>> the time into proper java or groovy code.
>>>>>>>>>
>>>>>>>>> As for the use of widgets over ftl, perhaps it is worth noting that
>>>>>>>>> we
>>>>>>>>> streamlined both for Scipio ERP. They share the same underlying set
>>>>>>>>> of
>>>>>>>>> macros and will create the hence create the same HTML & classes as
>>>>>>>>> are
>>>>>>>>> defined by your theme. So if people prefer to use widgets, they
>>>>>>>>> can.
>>>>>>>>> We
>>>>>>>>> relied on this, when cleaning up & converting usable screens alot,
>>>>>>>>> as not
>>>>>>>>> always it would make sense to transfer them to ftl.
>>>>>>>>>
>>>>>>>>> That being said, our goal is to further replace widgets by ftl
>>>>>>>>> logic
>>>>>>>>> as
>>>>>>>>>
>>>>>>>>> we
>>>>>>>>
>>>>>>>> move along. For both minilang and widgets the reason on our end is
>>>>>>>>> that
>>>>>>>>> neither technology is used anywhere outside of the ofbiz project
>>>>>>>>> and
>>>>>>>>> thus
>>>>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>>>>> rely on
>>>>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>
>
--
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
Re: Realistic lean Roadmap
Posted by Jacques Le Roux <ja...@les7arts.com>.
The idea is to focus team efforts on a small number of important goals rather than scatter energies on a lot of small goals
To stay focused we need a Roadmap, a simple and realistic one.
Jacques
Le 17/08/2016 � 19:05, Taher Alkhateeb a �crit :
> Hi Jacques,
>
> Would you kindly clarify the objective of the roadmap? What is the desired
> goal and how does it help? I think it is important to understand that to
> see if I would invest time and effort towards authoring the work.
>
> Taher Alkhatteb
>
> On Aug 17, 2016 6:48 PM, "Jacques Le Roux" <ja...@les7arts.com>
> wrote:
>
>> Hi All,
>>
>> I move and replace the "Ofbiz Cookbook" thread from the user ML since it
>> concerns more developers
>>
>> We need to have a very realistic lean Roadmap to agree on, follow and
>> progress.
>>
>> We can reuse https://cwiki.apache.org/confluence/display/OFBADMIN/New+
>> Features+Roadmap+-+Living+Document by simply prioritize the goals, then
>> pick up them as they come and prioritize again now and then when needed.
>>
>> We don't need to prioritize all tasks. Simply few that we put at top to
>> really work on them as a team and then sort again once they are done.
>> For that I have already added in this order "Introduce a plugin system"
>> and "Replace Minilang and widgets actions by a Groovy DSL"
>>
>> Also I don't think we need to maintain lists of "interested" and "willing
>> to help" people by goal. So I have removed this information. It's about
>> having a lean roadmap here, anybody can join at any moment. Rather links to
>> Jira can help to find people interested.
>>
>> I just removed the achieved or abandoned goals there:
>> Abandoned: Ivy integration (because of Gradle integration), Complete the
>> support for VAT(WIP was removed)
>> Achieved: Solr integration
>>
>> It simple and lean, what do you think?
>>
>> Jacques
>>
>>
>> Le 13/08/2016 � 10:19, Taher Alkhateeb a �crit :
>>
>>> +1
>>>
>>> On Aug 13, 2016 10:18 AM, "gil portenseigne" <gil.portenseigne@nereide.fr
>>> wrote:
>>>
>>> Yes i like this plan :)
>>>> Gil
>>>>
>>>> Le 12/08/2016 � 13:26, Jacques Le Roux a �crit :
>>>>
>>>> Yes, and I believe, when we will have worked out Gradle stuff (at least:
>>>>> finishing it, adding plugins, correctly documenting the whole) we should
>>>>> gather to work on this and slowly replace/improve the old good Minilang
>>>>>
>>>>> Could be the R17 main task?
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 12/08/2016 � 12:34, gil portenseigne a �crit :
>>>>>
>>>>> +1
>>>>>> Indeed, and moreover in the wiki page you link, there is autocompletion
>>>>>> configuration in IDE Integration part.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Gil
>>>>>>
>>>>>>
>>>>>> Le 12/08/2016 � 12:13, Jacques Le Roux a �crit :
>>>>>>
>>>>>> +1
>>>>>>> I think Jacopo has more to say about that :)
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
>>>>>>> DSL+for+OFBiz+business+logic
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 09/08/2016 � 19:11, Taher Alkhateeb a �crit :
>>>>>>>
>>>>>>> I would like to add to what Scott already mentioned that minilang is
>>>>>>>> not
>>>>>>>> only difficult to debug but also overly verbose.
>>>>>>>>
>>>>>>>> However, minilang exists and continues to be used I think because of
>>>>>>>> the
>>>>>>>> ctrl-space auto complete combined with XSD definitions for the
>>>>>>>> statements.
>>>>>>>> This makes it a DSL (not too pretty) and this is something that we
>>>>>>>> did
>>>>>>>> not
>>>>>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>>>>>> for an
>>>>>>>> alternative DSL but we don't have something yet which is
>>>>>>>> comprehensively
>>>>>>>> documented with an easy auto-complete feature. This is very important
>>>>>>>> for
>>>>>>>> many developers I think. So we need to think of a good alternative
>>>>>>>>
>>>>>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <
>>>>>>>> scott.gray@hotwaxsystems.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I'm certainly no fan of minilang. I prefer something I can step
>>>>>>>> through
>>>>>>>>
>>>>>>>>> with a debugger.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Scott
>>>>>>>>>
>>>>>>>>> On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
>>>>>>>>>
>>>>>>>>> Skip,
>>>>>>>>>
>>>>>>>>>> I fear that you may be right with regards to minilang and the
>>>>>>>>>> community,
>>>>>>>>>> though luckily with your own projects you can set your own
>>>>>>>>>> standards. I
>>>>>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>>>>>>>
>>>>>>>>>> though
>>>>>>>>> there are some benefits (the automapping of service maps or
>>>>>>>>>> entity-auto
>>>>>>>>>>
>>>>>>>>>> for
>>>>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>>>>>>> invest
>>>>>>>>> the time into proper java or groovy code.
>>>>>>>>>> As for the use of widgets over ftl, perhaps it is worth noting that
>>>>>>>>>> we
>>>>>>>>>> streamlined both for Scipio ERP. They share the same underlying set
>>>>>>>>>> of
>>>>>>>>>> macros and will create the hence create the same HTML & classes as
>>>>>>>>>> are
>>>>>>>>>> defined by your theme. So if people prefer to use widgets, they
>>>>>>>>>> can.
>>>>>>>>>> We
>>>>>>>>>> relied on this, when cleaning up & converting usable screens alot,
>>>>>>>>>> as not
>>>>>>>>>> always it would make sense to transfer them to ftl.
>>>>>>>>>>
>>>>>>>>>> That being said, our goal is to further replace widgets by ftl
>>>>>>>>>> logic
>>>>>>>>>> as
>>>>>>>>>>
>>>>>>>>>> we
>>>>>>>>> move along. For both minilang and widgets the reason on our end is
>>>>>>>>>> that
>>>>>>>>>> neither technology is used anywhere outside of the ofbiz project
>>>>>>>>>> and
>>>>>>>>>> thus
>>>>>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>>>>>> rely on
>>>>>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
Re: Realistic lean Roadmap [was Ofbiz Cookbook]
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacques,
Would you kindly clarify the objective of the roadmap? What is the desired
goal and how does it help? I think it is important to understand that to
see if I would invest time and effort towards authoring the work.
Taher Alkhatteb
On Aug 17, 2016 6:48 PM, "Jacques Le Roux" <ja...@les7arts.com>
wrote:
> Hi All,
>
> I move and replace the "Ofbiz Cookbook" thread from the user ML since it
> concerns more developers
>
> We need to have a very realistic lean Roadmap to agree on, follow and
> progress.
>
> We can reuse https://cwiki.apache.org/confluence/display/OFBADMIN/New+
> Features+Roadmap+-+Living+Document by simply prioritize the goals, then
> pick up them as they come and prioritize again now and then when needed.
>
> We don't need to prioritize all tasks. Simply few that we put at top to
> really work on them as a team and then sort again once they are done.
> For that I have already added in this order "Introduce a plugin system"
> and "Replace Minilang and widgets actions by a Groovy DSL"
>
> Also I don't think we need to maintain lists of "interested" and "willing
> to help" people by goal. So I have removed this information. It's about
> having a lean roadmap here, anybody can join at any moment. Rather links to
> Jira can help to find people interested.
>
> I just removed the achieved or abandoned goals there:
> Abandoned: Ivy integration (because of Gradle integration), Complete the
> support for VAT(WIP was removed)
> Achieved: Solr integration
>
> It simple and lean, what do you think?
>
> Jacques
>
>
> Le 13/08/2016 à 10:19, Taher Alkhateeb a écrit :
>
>> +1
>>
>> On Aug 13, 2016 10:18 AM, "gil portenseigne" <gil.portenseigne@nereide.fr
>> >
>> wrote:
>>
>> Yes i like this plan :)
>>>
>>> Gil
>>>
>>> Le 12/08/2016 à 13:26, Jacques Le Roux a écrit :
>>>
>>> Yes, and I believe, when we will have worked out Gradle stuff (at least:
>>>> finishing it, adding plugins, correctly documenting the whole) we should
>>>> gather to work on this and slowly replace/improve the old good Minilang
>>>>
>>>> Could be the R17 main task?
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 12/08/2016 à 12:34, gil portenseigne a écrit :
>>>>
>>>> +1
>>>>>
>>>>> Indeed, and moreover in the wiki page you link, there is autocompletion
>>>>> configuration in IDE Integration part.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Gil
>>>>>
>>>>>
>>>>> Le 12/08/2016 à 12:13, Jacques Le Roux a écrit :
>>>>>
>>>>> +1
>>>>>>
>>>>>> I think Jacopo has more to say about that :)
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
>>>>>> DSL+for+OFBiz+business+logic
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 09/08/2016 à 19:11, Taher Alkhateeb a écrit :
>>>>>>
>>>>>> I would like to add to what Scott already mentioned that minilang is
>>>>>>> not
>>>>>>> only difficult to debug but also overly verbose.
>>>>>>>
>>>>>>> However, minilang exists and continues to be used I think because of
>>>>>>> the
>>>>>>> ctrl-space auto complete combined with XSD definitions for the
>>>>>>> statements.
>>>>>>> This makes it a DSL (not too pretty) and this is something that we
>>>>>>> did
>>>>>>> not
>>>>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>>>>> for an
>>>>>>> alternative DSL but we don't have something yet which is
>>>>>>> comprehensively
>>>>>>> documented with an easy auto-complete feature. This is very important
>>>>>>> for
>>>>>>> many developers I think. So we need to think of a good alternative
>>>>>>>
>>>>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <
>>>>>>> scott.gray@hotwaxsystems.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I'm certainly no fan of minilang. I prefer something I can step
>>>>>>> through
>>>>>>>
>>>>>>>> with a debugger.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
>>>>>>>>
>>>>>>>> Skip,
>>>>>>>>
>>>>>>>>> I fear that you may be right with regards to minilang and the
>>>>>>>>> community,
>>>>>>>>> though luckily with your own projects you can set your own
>>>>>>>>> standards. I
>>>>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>>>>>>
>>>>>>>>> though
>>>>>>>>
>>>>>>>> there are some benefits (the automapping of service maps or
>>>>>>>>> entity-auto
>>>>>>>>>
>>>>>>>>> for
>>>>>>>>
>>>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>>>>>>
>>>>>>>>> invest
>>>>>>>>
>>>>>>>> the time into proper java or groovy code.
>>>>>>>>>
>>>>>>>>> As for the use of widgets over ftl, perhaps it is worth noting that
>>>>>>>>> we
>>>>>>>>> streamlined both for Scipio ERP. They share the same underlying set
>>>>>>>>> of
>>>>>>>>> macros and will create the hence create the same HTML & classes as
>>>>>>>>> are
>>>>>>>>> defined by your theme. So if people prefer to use widgets, they
>>>>>>>>> can.
>>>>>>>>> We
>>>>>>>>> relied on this, when cleaning up & converting usable screens alot,
>>>>>>>>> as not
>>>>>>>>> always it would make sense to transfer them to ftl.
>>>>>>>>>
>>>>>>>>> That being said, our goal is to further replace widgets by ftl
>>>>>>>>> logic
>>>>>>>>> as
>>>>>>>>>
>>>>>>>>> we
>>>>>>>>
>>>>>>>> move along. For both minilang and widgets the reason on our end is
>>>>>>>>> that
>>>>>>>>> neither technology is used anywhere outside of the ofbiz project
>>>>>>>>> and
>>>>>>>>> thus
>>>>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>>>>> rely on
>>>>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>
>
Realistic lean Roadmap [was Ofbiz Cookbook]
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi All,
I move and replace the "Ofbiz Cookbook" thread from the user ML since it concerns more developers
We need to have a very realistic lean Roadmap to agree on, follow and progress.
We can reuse https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document by simply prioritize the goals, then pick up
them as they come and prioritize again now and then when needed.
We don't need to prioritize all tasks. Simply few that we put at top to really work on them as a team and then sort again once they are done.
For that I have already added in this order "Introduce a plugin system" and "Replace Minilang and widgets actions by a Groovy DSL"
Also I don't think we need to maintain lists of "interested" and "willing to help" people by goal. So I have removed this information. It's about
having a lean roadmap here, anybody can join at any moment. Rather links to Jira can help to find people interested.
I just removed the achieved or abandoned goals there:
Abandoned: Ivy integration (because of Gradle integration), Complete the support for VAT(WIP was removed)
Achieved: Solr integration
It simple and lean, what do you think?
Jacques
Le 13/08/2016 � 10:19, Taher Alkhateeb a �crit :
> +1
>
> On Aug 13, 2016 10:18 AM, "gil portenseigne" <gi...@nereide.fr>
> wrote:
>
>> Yes i like this plan :)
>>
>> Gil
>>
>> Le 12/08/2016 � 13:26, Jacques Le Roux a �crit :
>>
>>> Yes, and I believe, when we will have worked out Gradle stuff (at least:
>>> finishing it, adding plugins, correctly documenting the whole) we should
>>> gather to work on this and slowly replace/improve the old good Minilang
>>>
>>> Could be the R17 main task?
>>>
>>> Jacques
>>>
>>>
>>> Le 12/08/2016 � 12:34, gil portenseigne a �crit :
>>>
>>>> +1
>>>>
>>>> Indeed, and moreover in the wiki page you link, there is autocompletion
>>>> configuration in IDE Integration part.
>>>>
>>>> Thanks
>>>>
>>>> Gil
>>>>
>>>>
>>>> Le 12/08/2016 � 12:13, Jacques Le Roux a �crit :
>>>>
>>>>> +1
>>>>>
>>>>> I think Jacopo has more to say about that :)
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
>>>>> DSL+for+OFBiz+business+logic
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 09/08/2016 � 19:11, Taher Alkhateeb a �crit :
>>>>>
>>>>>> I would like to add to what Scott already mentioned that minilang is
>>>>>> not
>>>>>> only difficult to debug but also overly verbose.
>>>>>>
>>>>>> However, minilang exists and continues to be used I think because of
>>>>>> the
>>>>>> ctrl-space auto complete combined with XSD definitions for the
>>>>>> statements.
>>>>>> This makes it a DSL (not too pretty) and this is something that we did
>>>>>> not
>>>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>>>> for an
>>>>>> alternative DSL but we don't have something yet which is
>>>>>> comprehensively
>>>>>> documented with an easy auto-complete feature. This is very important
>>>>>> for
>>>>>> many developers I think. So we need to think of a good alternative
>>>>>>
>>>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <
>>>>>> scott.gray@hotwaxsystems.com>
>>>>>> wrote:
>>>>>>
>>>>>> I'm certainly no fan of minilang. I prefer something I can step through
>>>>>>> with a debugger.
>>>>>>>
>>>>>>> Regards
>>>>>>> Scott
>>>>>>>
>>>>>>> On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
>>>>>>>
>>>>>>> Skip,
>>>>>>>> I fear that you may be right with regards to minilang and the
>>>>>>>> community,
>>>>>>>> though luckily with your own projects you can set your own
>>>>>>>> standards. I
>>>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>>>>>
>>>>>>> though
>>>>>>>
>>>>>>>> there are some benefits (the automapping of service maps or
>>>>>>>> entity-auto
>>>>>>>>
>>>>>>> for
>>>>>>>
>>>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>>>>>
>>>>>>> invest
>>>>>>>
>>>>>>>> the time into proper java or groovy code.
>>>>>>>>
>>>>>>>> As for the use of widgets over ftl, perhaps it is worth noting that
>>>>>>>> we
>>>>>>>> streamlined both for Scipio ERP. They share the same underlying set
>>>>>>>> of
>>>>>>>> macros and will create the hence create the same HTML & classes as
>>>>>>>> are
>>>>>>>> defined by your theme. So if people prefer to use widgets, they can.
>>>>>>>> We
>>>>>>>> relied on this, when cleaning up & converting usable screens alot,
>>>>>>>> as not
>>>>>>>> always it would make sense to transfer them to ftl.
>>>>>>>>
>>>>>>>> That being said, our goal is to further replace widgets by ftl logic
>>>>>>>> as
>>>>>>>>
>>>>>>> we
>>>>>>>
>>>>>>>> move along. For both minilang and widgets the reason on our end is
>>>>>>>> that
>>>>>>>> neither technology is used anywhere outside of the ofbiz project and
>>>>>>>> thus
>>>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>>>> rely on
>>>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Paul
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>
Re: Ofbiz Cookbook
Posted by Taher Alkhateeb <sl...@gmail.com>.
+1
On Aug 13, 2016 10:18 AM, "gil portenseigne" <gi...@nereide.fr>
wrote:
> Yes i like this plan :)
>
> Gil
>
> Le 12/08/2016 à 13:26, Jacques Le Roux a écrit :
>
>> Yes, and I believe, when we will have worked out Gradle stuff (at least:
>> finishing it, adding plugins, correctly documenting the whole) we should
>> gather to work on this and slowly replace/improve the old good Minilang
>>
>> Could be the R17 main task?
>>
>> Jacques
>>
>>
>> Le 12/08/2016 à 12:34, gil portenseigne a écrit :
>>
>>>
>>> +1
>>>
>>> Indeed, and moreover in the wiki page you link, there is autocompletion
>>> configuration in IDE Integration part.
>>>
>>> Thanks
>>>
>>> Gil
>>>
>>>
>>> Le 12/08/2016 à 12:13, Jacques Le Roux a écrit :
>>>
>>>> +1
>>>>
>>>> I think Jacopo has more to say about that :)
>>>>
>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
>>>> DSL+for+OFBiz+business+logic
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 09/08/2016 à 19:11, Taher Alkhateeb a écrit :
>>>>
>>>>> I would like to add to what Scott already mentioned that minilang is
>>>>> not
>>>>> only difficult to debug but also overly verbose.
>>>>>
>>>>> However, minilang exists and continues to be used I think because of
>>>>> the
>>>>> ctrl-space auto complete combined with XSD definitions for the
>>>>> statements.
>>>>> This makes it a DSL (not too pretty) and this is something that we did
>>>>> not
>>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>>> for an
>>>>> alternative DSL but we don't have something yet which is
>>>>> comprehensively
>>>>> documented with an easy auto-complete feature. This is very important
>>>>> for
>>>>> many developers I think. So we need to think of a good alternative
>>>>>
>>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <
>>>>> scott.gray@hotwaxsystems.com>
>>>>> wrote:
>>>>>
>>>>> I'm certainly no fan of minilang. I prefer something I can step through
>>>>>> with a debugger.
>>>>>>
>>>>>> Regards
>>>>>> Scott
>>>>>>
>>>>>> On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
>>>>>>
>>>>>> Skip,
>>>>>>>
>>>>>>> I fear that you may be right with regards to minilang and the
>>>>>>> community,
>>>>>>> though luckily with your own projects you can set your own
>>>>>>> standards. I
>>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>>>>
>>>>>> though
>>>>>>
>>>>>>> there are some benefits (the automapping of service maps or
>>>>>>> entity-auto
>>>>>>>
>>>>>> for
>>>>>>
>>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>>>>
>>>>>> invest
>>>>>>
>>>>>>> the time into proper java or groovy code.
>>>>>>>
>>>>>>> As for the use of widgets over ftl, perhaps it is worth noting that
>>>>>>> we
>>>>>>> streamlined both for Scipio ERP. They share the same underlying set
>>>>>>> of
>>>>>>> macros and will create the hence create the same HTML & classes as
>>>>>>> are
>>>>>>> defined by your theme. So if people prefer to use widgets, they can.
>>>>>>> We
>>>>>>> relied on this, when cleaning up & converting usable screens alot,
>>>>>>> as not
>>>>>>> always it would make sense to transfer them to ftl.
>>>>>>>
>>>>>>> That being said, our goal is to further replace widgets by ftl logic
>>>>>>> as
>>>>>>>
>>>>>> we
>>>>>>
>>>>>>> move along. For both minilang and widgets the reason on our end is
>>>>>>> that
>>>>>>> neither technology is used anywhere outside of the ofbiz project and
>>>>>>> thus
>>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>>> rely on
>>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Paul
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>
>>>
>>
>>
>
Re: Ofbiz Cookbook
Posted by gil portenseigne <gi...@nereide.fr>.
Yes i like this plan :)
Gil
Le 12/08/2016 � 13:26, Jacques Le Roux a �crit :
> Yes, and I believe, when we will have worked out Gradle stuff (at
> least: finishing it, adding plugins, correctly documenting the whole)
> we should gather to work on this and slowly replace/improve the old
> good Minilang
>
> Could be the R17 main task?
>
> Jacques
>
>
> Le 12/08/2016 � 12:34, gil portenseigne a �crit :
>>
>> +1
>>
>> Indeed, and moreover in the wiki page you link, there is
>> autocompletion configuration in IDE Integration part.
>>
>> Thanks
>>
>> Gil
>>
>>
>> Le 12/08/2016 � 12:13, Jacques Le Roux a �crit :
>>> +1
>>>
>>> I think Jacopo has more to say about that :)
>>>
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic
>>>
>>>
>>> Jacques
>>>
>>>
>>> Le 09/08/2016 � 19:11, Taher Alkhateeb a �crit :
>>>> I would like to add to what Scott already mentioned that minilang
>>>> is not
>>>> only difficult to debug but also overly verbose.
>>>>
>>>> However, minilang exists and continues to be used I think because
>>>> of the
>>>> ctrl-space auto complete combined with XSD definitions for the
>>>> statements.
>>>> This makes it a DSL (not too pretty) and this is something that we
>>>> did not
>>>> provide a reasonable alternative for. Groovy makes a good candidate
>>>> for an
>>>> alternative DSL but we don't have something yet which is
>>>> comprehensively
>>>> documented with an easy auto-complete feature. This is very
>>>> important for
>>>> many developers I think. So we need to think of a good alternative
>>>>
>>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray
>>>> <sc...@hotwaxsystems.com>
>>>> wrote:
>>>>
>>>>> I'm certainly no fan of minilang. I prefer something I can step
>>>>> through
>>>>> with a debugger.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
>>>>>
>>>>>> Skip,
>>>>>>
>>>>>> I fear that you may be right with regards to minilang and the
>>>>>> community,
>>>>>> though luckily with your own projects you can set your own
>>>>>> standards. I
>>>>>> learned the hard way that minilang leads to more cluttered code and
>>>>> though
>>>>>> there are some benefits (the automapping of service maps or
>>>>>> entity-auto
>>>>> for
>>>>>> creating crud services), I would strongly recommend anyone to rather
>>>>> invest
>>>>>> the time into proper java or groovy code.
>>>>>>
>>>>>> As for the use of widgets over ftl, perhaps it is worth noting
>>>>>> that we
>>>>>> streamlined both for Scipio ERP. They share the same underlying
>>>>>> set of
>>>>>> macros and will create the hence create the same HTML & classes
>>>>>> as are
>>>>>> defined by your theme. So if people prefer to use widgets, they
>>>>>> can. We
>>>>>> relied on this, when cleaning up & converting usable screens
>>>>>> alot, as not
>>>>>> always it would make sense to transfer them to ftl.
>>>>>>
>>>>>> That being said, our goal is to further replace widgets by ftl
>>>>>> logic as
>>>>> we
>>>>>> move along. For both minilang and widgets the reason on our end
>>>>>> is that
>>>>>> neither technology is used anywhere outside of the ofbiz project
>>>>>> and thus
>>>>>> adds to the overall learning-curve for newcomers. We much rather
>>>>>> rely on
>>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>>
>>>>>> Cheers,
>>>>>> Paul
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>
>>>
>>
>
>
Re: Ofbiz Cookbook
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes, and I believe, when we will have worked out Gradle stuff (at least: finishing it, adding plugins, correctly documenting the whole) we should
gather to work on this and slowly replace/improve the old good Minilang
Could be the R17 main task?
Jacques
Le 12/08/2016 � 12:34, gil portenseigne a �crit :
>
> +1
>
> Indeed, and moreover in the wiki page you link, there is autocompletion configuration in IDE Integration part.
>
> Thanks
>
> Gil
>
>
> Le 12/08/2016 � 12:13, Jacques Le Roux a �crit :
>> +1
>>
>> I think Jacopo has more to say about that :)
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic
>>
>> Jacques
>>
>>
>> Le 09/08/2016 � 19:11, Taher Alkhateeb a �crit :
>>> I would like to add to what Scott already mentioned that minilang is not
>>> only difficult to debug but also overly verbose.
>>>
>>> However, minilang exists and continues to be used I think because of the
>>> ctrl-space auto complete combined with XSD definitions for the statements.
>>> This makes it a DSL (not too pretty) and this is something that we did not
>>> provide a reasonable alternative for. Groovy makes a good candidate for an
>>> alternative DSL but we don't have something yet which is comprehensively
>>> documented with an easy auto-complete feature. This is very important for
>>> many developers I think. So we need to think of a good alternative
>>>
>>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <sc...@hotwaxsystems.com>
>>> wrote:
>>>
>>>> I'm certainly no fan of minilang. I prefer something I can step through
>>>> with a debugger.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
>>>>
>>>>> Skip,
>>>>>
>>>>> I fear that you may be right with regards to minilang and the community,
>>>>> though luckily with your own projects you can set your own standards. I
>>>>> learned the hard way that minilang leads to more cluttered code and
>>>> though
>>>>> there are some benefits (the automapping of service maps or entity-auto
>>>> for
>>>>> creating crud services), I would strongly recommend anyone to rather
>>>> invest
>>>>> the time into proper java or groovy code.
>>>>>
>>>>> As for the use of widgets over ftl, perhaps it is worth noting that we
>>>>> streamlined both for Scipio ERP. They share the same underlying set of
>>>>> macros and will create the hence create the same HTML & classes as are
>>>>> defined by your theme. So if people prefer to use widgets, they can. We
>>>>> relied on this, when cleaning up & converting usable screens alot, as not
>>>>> always it would make sense to transfer them to ftl.
>>>>>
>>>>> That being said, our goal is to further replace widgets by ftl logic as
>>>> we
>>>>> move along. For both minilang and widgets the reason on our end is that
>>>>> neither technology is used anywhere outside of the ofbiz project and thus
>>>>> adds to the overall learning-curve for newcomers. We much rather rely on
>>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>>
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>
>>
>
Re: Ofbiz Cookbook
Posted by gil portenseigne <gi...@nereide.fr>.
+1
Indeed, and moreover in the wiki page you link, there is autocompletion
configuration in IDE Integration part.
Thanks
Gil
Le 12/08/2016 � 12:13, Jacques Le Roux a �crit :
> +1
>
> I think Jacopo has more to say about that :)
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic
>
>
> Jacques
>
>
> Le 09/08/2016 � 19:11, Taher Alkhateeb a �crit :
>> I would like to add to what Scott already mentioned that minilang is not
>> only difficult to debug but also overly verbose.
>>
>> However, minilang exists and continues to be used I think because of the
>> ctrl-space auto complete combined with XSD definitions for the
>> statements.
>> This makes it a DSL (not too pretty) and this is something that we
>> did not
>> provide a reasonable alternative for. Groovy makes a good candidate
>> for an
>> alternative DSL but we don't have something yet which is comprehensively
>> documented with an easy auto-complete feature. This is very important
>> for
>> many developers I think. So we need to think of a good alternative
>>
>> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray
>> <sc...@hotwaxsystems.com>
>> wrote:
>>
>>> I'm certainly no fan of minilang. I prefer something I can step through
>>> with a debugger.
>>>
>>> Regards
>>> Scott
>>>
>>> On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
>>>
>>>> Skip,
>>>>
>>>> I fear that you may be right with regards to minilang and the
>>>> community,
>>>> though luckily with your own projects you can set your own
>>>> standards. I
>>>> learned the hard way that minilang leads to more cluttered code and
>>> though
>>>> there are some benefits (the automapping of service maps or
>>>> entity-auto
>>> for
>>>> creating crud services), I would strongly recommend anyone to rather
>>> invest
>>>> the time into proper java or groovy code.
>>>>
>>>> As for the use of widgets over ftl, perhaps it is worth noting that we
>>>> streamlined both for Scipio ERP. They share the same underlying set of
>>>> macros and will create the hence create the same HTML & classes as are
>>>> defined by your theme. So if people prefer to use widgets, they
>>>> can. We
>>>> relied on this, when cleaning up & converting usable screens alot,
>>>> as not
>>>> always it would make sense to transfer them to ftl.
>>>>
>>>> That being said, our goal is to further replace widgets by ftl
>>>> logic as
>>> we
>>>> move along. For both minilang and widgets the reason on our end is
>>>> that
>>>> neither technology is used anywhere outside of the ofbiz project
>>>> and thus
>>>> adds to the overall learning-curve for newcomers. We much rather
>>>> rely on
>>>> trusted alternatives that are easier to pick up for our project ;)
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>
>
Re: Ofbiz Cookbook
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Fri, Aug 12, 2016 at 12:13 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> +1
>
> I think Jacopo has more to say about that :)
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+
> DSL+for+OFBiz+business+logic
>
> Jacques
>
>
Agreed. We could improve the ideas outlined in the current "Groovy DSL for
OFBiz", for which we have in trunk a "plugin" for Eclipse and IntelliJ
(that provides autocompletion); and start converting existing Minilang code
to it.
Jacopo
Re: Ofbiz Cookbook
Posted by Jacques Le Roux <ja...@les7arts.com>.
+1
I think Jacopo has more to say about that :)
https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic
Jacques
Le 09/08/2016 � 19:11, Taher Alkhateeb a �crit :
> I would like to add to what Scott already mentioned that minilang is not
> only difficult to debug but also overly verbose.
>
> However, minilang exists and continues to be used I think because of the
> ctrl-space auto complete combined with XSD definitions for the statements.
> This makes it a DSL (not too pretty) and this is something that we did not
> provide a reasonable alternative for. Groovy makes a good candidate for an
> alternative DSL but we don't have something yet which is comprehensively
> documented with an easy auto-complete feature. This is very important for
> many developers I think. So we need to think of a good alternative
>
> On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <sc...@hotwaxsystems.com>
> wrote:
>
>> I'm certainly no fan of minilang. I prefer something I can step through
>> with a debugger.
>>
>> Regards
>> Scott
>>
>> On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
>>
>>> Skip,
>>>
>>> I fear that you may be right with regards to minilang and the community,
>>> though luckily with your own projects you can set your own standards. I
>>> learned the hard way that minilang leads to more cluttered code and
>> though
>>> there are some benefits (the automapping of service maps or entity-auto
>> for
>>> creating crud services), I would strongly recommend anyone to rather
>> invest
>>> the time into proper java or groovy code.
>>>
>>> As for the use of widgets over ftl, perhaps it is worth noting that we
>>> streamlined both for Scipio ERP. They share the same underlying set of
>>> macros and will create the hence create the same HTML & classes as are
>>> defined by your theme. So if people prefer to use widgets, they can. We
>>> relied on this, when cleaning up & converting usable screens alot, as not
>>> always it would make sense to transfer them to ftl.
>>>
>>> That being said, our goal is to further replace widgets by ftl logic as
>> we
>>> move along. For both minilang and widgets the reason on our end is that
>>> neither technology is used anywhere outside of the ofbiz project and thus
>>> adds to the overall learning-curve for newcomers. We much rather rely on
>>> trusted alternatives that are easier to pick up for our project ;)
>>>
>>> Cheers,
>>> Paul
>>>
>>>
>>>
>>> --
>>> View this message in context: http://ofbiz.135035.n4.nabble.
>>> com/Ofbiz-Cookbook-tp4690647p4690733.html
>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>
Re: Ofbiz Cookbook
Posted by Taher Alkhateeb <sl...@gmail.com>.
I would like to add to what Scott already mentioned that minilang is not
only difficult to debug but also overly verbose.
However, minilang exists and continues to be used I think because of the
ctrl-space auto complete combined with XSD definitions for the statements.
This makes it a DSL (not too pretty) and this is something that we did not
provide a reasonable alternative for. Groovy makes a good candidate for an
alternative DSL but we don't have something yet which is comprehensively
documented with an easy auto-complete feature. This is very important for
many developers I think. So we need to think of a good alternative
On Tue, Aug 9, 2016 at 1:34 PM, Scott Gray <sc...@hotwaxsystems.com>
wrote:
> I'm certainly no fan of minilang. I prefer something I can step through
> with a debugger.
>
> Regards
> Scott
>
> On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
>
> > Skip,
> >
> > I fear that you may be right with regards to minilang and the community,
> > though luckily with your own projects you can set your own standards. I
> > learned the hard way that minilang leads to more cluttered code and
> though
> > there are some benefits (the automapping of service maps or entity-auto
> for
> > creating crud services), I would strongly recommend anyone to rather
> invest
> > the time into proper java or groovy code.
> >
> > As for the use of widgets over ftl, perhaps it is worth noting that we
> > streamlined both for Scipio ERP. They share the same underlying set of
> > macros and will create the hence create the same HTML & classes as are
> > defined by your theme. So if people prefer to use widgets, they can. We
> > relied on this, when cleaning up & converting usable screens alot, as not
> > always it would make sense to transfer them to ftl.
> >
> > That being said, our goal is to further replace widgets by ftl logic as
> we
> > move along. For both minilang and widgets the reason on our end is that
> > neither technology is used anywhere outside of the ofbiz project and thus
> > adds to the overall learning-curve for newcomers. We much rather rely on
> > trusted alternatives that are easier to pick up for our project ;)
> >
> > Cheers,
> > Paul
> >
> >
> >
> > --
> > View this message in context: http://ofbiz.135035.n4.nabble.
> > com/Ofbiz-Cookbook-tp4690647p4690733.html
> > Sent from the OFBiz - User mailing list archive at Nabble.com.
> >
>
RE: Ofbiz Cookbook
Posted by Scott Gray <sc...@hotwaxsystems.com>.
I'm certainly no fan of minilang. I prefer something I can step through
with a debugger.
Regards
Scott
On 9/08/2016 20:55, "Paul Piper" <pp...@ilscipio.com> wrote:
> Skip,
>
> I fear that you may be right with regards to minilang and the community,
> though luckily with your own projects you can set your own standards. I
> learned the hard way that minilang leads to more cluttered code and though
> there are some benefits (the automapping of service maps or entity-auto for
> creating crud services), I would strongly recommend anyone to rather invest
> the time into proper java or groovy code.
>
> As for the use of widgets over ftl, perhaps it is worth noting that we
> streamlined both for Scipio ERP. They share the same underlying set of
> macros and will create the hence create the same HTML & classes as are
> defined by your theme. So if people prefer to use widgets, they can. We
> relied on this, when cleaning up & converting usable screens alot, as not
> always it would make sense to transfer them to ftl.
>
> That being said, our goal is to further replace widgets by ftl logic as we
> move along. For both minilang and widgets the reason on our end is that
> neither technology is used anywhere outside of the ofbiz project and thus
> adds to the overall learning-curve for newcomers. We much rather rely on
> trusted alternatives that are easier to pick up for our project ;)
>
> Cheers,
> Paul
>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.
> com/Ofbiz-Cookbook-tp4690647p4690733.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
RE: Ofbiz Cookbook
Posted by Skip <sk...@thedevers.org>.
...
For both minilang and widgets the reason on our end is that
neither technology is used anywhere outside of the ofbiz project and thus
adds to the overall learning-curve for newcomers. We much rather rely on
trusted alternatives that are easier to pick up for our project ;)
Cheers,
Paul
I couldn't agree more Paul. Everyone we hire has to learn minilang and it
does indeed significantly add to the learning curve.
RE: Ofbiz Cookbook
Posted by Paul Piper <pp...@ilscipio.com>.
Skip,
I fear that you may be right with regards to minilang and the community,
though luckily with your own projects you can set your own standards. I
learned the hard way that minilang leads to more cluttered code and though
there are some benefits (the automapping of service maps or entity-auto for
creating crud services), I would strongly recommend anyone to rather invest
the time into proper java or groovy code.
As for the use of widgets over ftl, perhaps it is worth noting that we
streamlined both for Scipio ERP. They share the same underlying set of
macros and will create the hence create the same HTML & classes as are
defined by your theme. So if people prefer to use widgets, they can. We
relied on this, when cleaning up & converting usable screens alot, as not
always it would make sense to transfer them to ftl.
That being said, our goal is to further replace widgets by ftl logic as we
move along. For both minilang and widgets the reason on our end is that
neither technology is used anywhere outside of the ofbiz project and thus
adds to the overall learning-curve for newcomers. We much rather rely on
trusted alternatives that are easier to pick up for our project ;)
Cheers,
Paul
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Ofbiz-Cookbook-tp4690647p4690733.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
RE: Ofbiz Cookbook
Posted by Skip <sk...@thedevers.org>.
Paul
I took the time to scan your link, but did not get into an in-depth perusal
of it. At first glance, it is a fine overview, but in my opinion, not
nearly complete enough for a new user. For this, I think Ruth's book is
much more useful.
I do like your decision to replace all the minilang services. I too have
slowly been replacing them for my installations. On the other hand, I
really like minilang screens for simple backend stuff. You can write them
much more quickly than ftl so long as they are simple.
I also really like your new ftl macros. I have been using the opentaps
macros for a long time and I think yours are significantly better especially
in their granularity and ability to support more display device types. I
think Obbiz would greatly benefit if you considered contributing them back
to the Obbiz project.
Having said that, I am not sure there would be a consensus on the shift back
to ftl. So many of the active contributors seem to like minilang. I think
that is one of the reasons Si Chen started opentaps.
I completely missed seeing that Ruth had moved on. That is sad. But
hopefully, she is still getting royalities for her work.
Skip
-----Original Message-----
From: Paul Piper [mailto:pp@ilscipio.com]
Sent: Saturday, August 06, 2016 1:53 AM
To: user@ofbiz.apache.org
Subject: Re: Ofbiz Cookbook
Hi Skip,
thanks for sharing. I completely agree with you on your opinion about the
books. We did a project together with Ruth before she left the community and
I said before that I think it is a shame that the community wasn't able to
value her contribution for what it is. Just like Rupert Howell's book, which
i can also highly recommend, the book is the standard textbook for all new
ofbiz developers and we recommend it to all customers we train.
Perhaps you would also be interested in checking out the Scipio
documentation: http://www.scipioerp.com/community/developer/architecture/
We try to maintain an easy to understand guideline that should be suitable
for beginners. I would love to hear your feedback on it.
Regards,
Paul
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Ofbiz-Cookbook-tp4690647p4690671.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Ofbiz Cookbook
Posted by Paul Piper <pp...@ilscipio.com>.
Hi Skip,
thanks for sharing. I completely agree with you on your opinion about the
books. We did a project together with Ruth before she left the community and
I said before that I think it is a shame that the community wasn't able to
value her contribution for what it is. Just like Rupert Howell's book, which
i can also highly recommend, the book is the standard textbook for all new
ofbiz developers and we recommend it to all customers we train.
Perhaps you would also be interested in checking out the Scipio
documentation: http://www.scipioerp.com/community/developer/architecture/
We try to maintain an easy to understand guideline that should be suitable
for beginners. I would love to hear your feedback on it.
Regards,
Paul
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Ofbiz-Cookbook-tp4690647p4690671.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
RE: Re: Ofbiz Cookbook
Posted by user <xx...@rambler.ru>.
It has been passed 6 yrs, but Kindle version costs $17. I wonder, If the author (not publisher) still earns money on sales of the book?
> 06.08.2016, 5:15:23 пользователь Todd Thorner (tthorner@infotinuum.com) написал:
>
> Thanks very much, Skip, for the information. Sounds like a great book.
> I haven't done Java since Struts 1.x, so I'll need to shake off some
> language rust (not the language Rust but just plain old ordinary
> language rust).
>
> On 16-08-05 03:27 PM, Skip wrote:
> > There have been significant changes since this book was written. However,
> > it covers topics where very little would need to be added to make it
> > current. It does not cover the code in the applications tree where a great
> > deal has changed. It focuses on the framework which is what you really want
> > when you are making new applications for hot-deploy. I think with this
> > book, you are well prepared to write new applications assuming previous Java
> > experience.
> >
> > -----Original Message-----
> > From: Todd Thorner [mailto:tthorner@infotinuum.com]
> > Sent: Friday, August 05, 2016 1:00 PM
> > To: user@ofbiz.apache.org
> > Subject: Re: Ofbiz Cookbook
> >
> >
> > Thank you for the recommendation. I read Ms. Hoffman's "OFBiz Ecommerce
> > Out-Of-The-Box" as a primer of sorts, and based on that positive
> > experience will consider saving my pennies so I can purchase her OFBiz
> > cookbook.
> >
> > Is there any reason to anticipate a need for an updated edition? Have
> > there been many significant changes to OFBiz (or its complementary
> > considerations like data modeling strategies) since 2010?
> >
> >
> >
> > On 16-08-05 10:55 AM, Skip wrote:
> >> I just got finished reading Apache OFBiz Cookbook (Open Source: Community
> >> Experience Distilled) by Ruth Hoffman.
> >>
> >> I have been writing Ofbiz code since before it was an Apache project.
> > This
> >> book would have saved me six months of digging through Ofbiz code and
> >> inspite of my nearly a decade of experience, I still learned several new
> >> things in it.
> >>
> >> I highly recommend this book to everyone, beginner and expert alike and
> >> strongly recommend this book for anyone just getting started. It is well
> >> written and worth every penny. When you get the Data Resource book, get
> >> this one too and read it first.
> >>
> >> Amazon has it here
> >>
> > https://www.amazon.com/gp/product/1847199186/ref=oh_aui_detailpage_o05_s00?i
> >> e=UTF8&psc=1
> >>
> >>
> >> I have never met or spoken to Ruth even though she posts on this forum
> > from
> >> time to time.
> >>
> >> Thanks Ruth.
> >>
> >> Skip
> >>
> >
>
>
Re: Ofbiz Cookbook
Posted by Todd Thorner <tt...@infotinuum.com>.
Thanks very much, Skip, for the information. Sounds like a great book.
I haven't done Java since Struts 1.x, so I'll need to shake off some
language rust (not the language Rust but just plain old ordinary
language rust).
On 16-08-05 03:27 PM, Skip wrote:
> There have been significant changes since this book was written. However,
> it covers topics where very little would need to be added to make it
> current. It does not cover the code in the applications tree where a great
> deal has changed. It focuses on the framework which is what you really want
> when you are making new applications for hot-deploy. I think with this
> book, you are well prepared to write new applications assuming previous Java
> experience.
>
> -----Original Message-----
> From: Todd Thorner [mailto:tthorner@infotinuum.com]
> Sent: Friday, August 05, 2016 1:00 PM
> To: user@ofbiz.apache.org
> Subject: Re: Ofbiz Cookbook
>
>
> Thank you for the recommendation. I read Ms. Hoffman's "OFBiz Ecommerce
> Out-Of-The-Box" as a primer of sorts, and based on that positive
> experience will consider saving my pennies so I can purchase her OFBiz
> cookbook.
>
> Is there any reason to anticipate a need for an updated edition? Have
> there been many significant changes to OFBiz (or its complementary
> considerations like data modeling strategies) since 2010?
>
>
>
> On 16-08-05 10:55 AM, Skip wrote:
>> I just got finished reading Apache OFBiz Cookbook (Open Source: Community
>> Experience Distilled) by Ruth Hoffman.
>>
>> I have been writing Ofbiz code since before it was an Apache project.
> This
>> book would have saved me six months of digging through Ofbiz code and
>> inspite of my nearly a decade of experience, I still learned several new
>> things in it.
>>
>> I highly recommend this book to everyone, beginner and expert alike and
>> strongly recommend this book for anyone just getting started. It is well
>> written and worth every penny. When you get the Data Resource book, get
>> this one too and read it first.
>>
>> Amazon has it here
>>
> https://www.amazon.com/gp/product/1847199186/ref=oh_aui_detailpage_o05_s00?i
>> e=UTF8&psc=1
>>
>>
>> I have never met or spoken to Ruth even though she posts on this forum
> from
>> time to time.
>>
>> Thanks Ruth.
>>
>> Skip
>>
>
RE: Ofbiz Cookbook
Posted by Skip <sk...@thedevers.org>.
There have been significant changes since this book was written. However,
it covers topics where very little would need to be added to make it
current. It does not cover the code in the applications tree where a great
deal has changed. It focuses on the framework which is what you really want
when you are making new applications for hot-deploy. I think with this
book, you are well prepared to write new applications assuming previous Java
experience.
-----Original Message-----
From: Todd Thorner [mailto:tthorner@infotinuum.com]
Sent: Friday, August 05, 2016 1:00 PM
To: user@ofbiz.apache.org
Subject: Re: Ofbiz Cookbook
Thank you for the recommendation. I read Ms. Hoffman's "OFBiz Ecommerce
Out-Of-The-Box" as a primer of sorts, and based on that positive
experience will consider saving my pennies so I can purchase her OFBiz
cookbook.
Is there any reason to anticipate a need for an updated edition? Have
there been many significant changes to OFBiz (or its complementary
considerations like data modeling strategies) since 2010?
On 16-08-05 10:55 AM, Skip wrote:
> I just got finished reading Apache OFBiz Cookbook (Open Source: Community
> Experience Distilled) by Ruth Hoffman.
>
> I have been writing Ofbiz code since before it was an Apache project.
This
> book would have saved me six months of digging through Ofbiz code and
> inspite of my nearly a decade of experience, I still learned several new
> things in it.
>
> I highly recommend this book to everyone, beginner and expert alike and
> strongly recommend this book for anyone just getting started. It is well
> written and worth every penny. When you get the Data Resource book, get
> this one too and read it first.
>
> Amazon has it here
>
https://www.amazon.com/gp/product/1847199186/ref=oh_aui_detailpage_o05_s00?i
> e=UTF8&psc=1
>
>
> I have never met or spoken to Ruth even though she posts on this forum
from
> time to time.
>
> Thanks Ruth.
>
> Skip
>
Re: Ofbiz Cookbook
Posted by Todd Thorner <tt...@infotinuum.com>.
Thank you for the recommendation. I read Ms. Hoffman's "OFBiz Ecommerce
Out-Of-The-Box" as a primer of sorts, and based on that positive
experience will consider saving my pennies so I can purchase her OFBiz
cookbook.
Is there any reason to anticipate a need for an updated edition? Have
there been many significant changes to OFBiz (or its complementary
considerations like data modeling strategies) since 2010?
On 16-08-05 10:55 AM, Skip wrote:
> I just got finished reading Apache OFBiz Cookbook (Open Source: Community
> Experience Distilled) by Ruth Hoffman.
>
> I have been writing Ofbiz code since before it was an Apache project. This
> book would have saved me six months of digging through Ofbiz code and
> inspite of my nearly a decade of experience, I still learned several new
> things in it.
>
> I highly recommend this book to everyone, beginner and expert alike and
> strongly recommend this book for anyone just getting started. It is well
> written and worth every penny. When you get the Data Resource book, get
> this one too and read it first.
>
> Amazon has it here
> https://www.amazon.com/gp/product/1847199186/ref=oh_aui_detailpage_o05_s00?i
> e=UTF8&psc=1
>
>
> I have never met or spoken to Ruth even though she posts on this forum from
> time to time.
>
> Thanks Ruth.
>
> Skip
>