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" <[email protected]>
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" <[email protected]
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 <
[email protected]>
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" <[email protected]> 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.
