Lose Weight Program for OFBiz

[Divesh Dutta]

My +1 for moving them to Extras. Reason is, if we need to keep it for  best practice guide or for training then no doubt its a extra work.  We can give good documentation with details about how to use /extras/example component to learn and keep it as best practice guide. Also we can promote this in user mailing lists .

Thanks
--
Divesh

On Mar 21, 2012, at 4:14 AM, Jacques Le Roux wrote:

> From: "Mansour Al Akeel" <[hidden email]>
>> Everyone has different preference about how would the basic component
>> skeleton looks like (ie, with ajax, without, exta functionality ....
>> ).
>> Even if a basic example included with ofbiz distribution, in the
>> future it will grow again with extra unneeded functionality, or it
>> will be an on going discussion about what should go there.
>>
>> It's much easier to provide a very basic skeleton as a separate
>> download, to serve as an example and a reference. There could be more
>> than one example provided, each showing different capabilities and
>> different techniques. This is better than creating one huge example to
>> show everything, and better than showing only the basics without any
>> additional tips (ie, ajax).
>>
>> Those who are not satisfied with the examples as a skeleton, can
>> maintain their own copy that will make him/her start a component
>> quickly.
>>
>> Examples are not needed to run ofbiz.
>
> So they (examples and examplesext) could be in specialpurpose (+1) of even Extras (0)
>
> Jacques
>
>>
>> On Tue, Mar 20, 2012 at 4:33 PM, Erwan de FERRIERES
>> <[hidden email]> wrote:
>>> Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
>>>>>
>>>>> Q) framework/example and framework/exampleext: move to specialpurpose
>>>>
>>>>
>>>> Adrian would like to keep Example in the framework but slim it down a lot
>>>> to the essential (no form widgets examples, no Ajax examples, no content
>>>> examples etc...). Adrian would you please confirm if in your vision the
>>>> "example" application should document the layout of a typical OFBiz
>>>> component only? If yes, we could use the output of the "ant
>>>> create-component" task to document the best practice layout.
>>>> Jacques, Olivier would like to keep also the examples for the various
>>>> higher level features available to OFBiz applications.
>>>>
>>>> I think that from the discussion it could emerge the following solution to
>>>> please everyone:
>>>>
>>>> * keep the "example" component in the framework but slim it down to the
>>>> bare essential
>>>> * move the "exampleext" component to specialpurpose and migrate to it all
>>>> the extra features: this could also be used as a best practice guide on how
>>>> to extend a component from hot-deploy/specialpurpose
>>>>
>>>> I still think that it would be nicer to not bundle the "example" component
>>>> ootb to keep the framework cleaner: the example should be downloaded
>>>> separately (when we will have clear separation between framework and the
>>>> rest); this approach is similar to tomcat and its example applications. But
>>>> I don't have a strong opinion on this.
>>>>
>>>> Jacopo
>>>>
>>>>
>>> create 2 components, one basic with simple CRUD and no ajax or whatever, and
>>> another one with more eye candy stuff (ajax, modal forms, etc...). Both
>>> components should be in specialpurpose/
>>> I'm not in favor of moving them to extras, as when delivering an official
>>> release there should be a showcase included. And as Adrian said, when
>>> teaching people how to create apps with OFBiz, this could be really useful.
>>> And with JSR-223, there's a lot to add !
>>>
>>> --
>>> Erwan de FERRIERES
>>> www.nereide.biz

[Adrian Crum-3]

We could include a metadata interface that external reporting tools to
can use to generate reports.

-Adrian

On 4/3/2012 10:27 AM, Divesh Dutta wrote:

> +1 for Adrian.
>
> IT departments use specific tools. And they would like to integrate those tools with OFBiz. So any reporting tool should go in Extras and End User should download them as per their need. We just need good documentation around all these efforts to help end users.
>
> Thanks
> --
> Divesh
>
> On Mar 20, 2012, at 8:01 PM, [hidden email] wrote:
>
>> I like the idea of keeping reporting tools separate from OFBiz. In my experience, IT departments are already using a reporting tool for other applications and they would prefer to integrate that tool with OFBiz, instead of learning/using a new tool that comes bundled with it.
>>
>> -Adrian
>>
>> Quoting Jacopo Cappellato<[hidden email]>:
>>
>>>> L) framework/birt (and related dependencies/reports spread around): move to "Extras"
>>>>
>>>> M) framework/bi (and related dependencies - ecas/business rules and data - spread around): move to "Extras"
>>>>
>>> This is an area where Hans and I are in disagreement and we didn't get much feedback from others.
>>>
>>> So I would like to explain here why I think we should move the Birt component and the Birt reports out of the framework and consider them as optional tools.
>>>
>>> There are currently 18 reports in the applications implemented with Birt; but they really seem experiments rather than something really usable; to give you some examples:
>>>
>>> * in most of them there is this code like this:
>>>
>>> userLogin = null;
>>> try {
>>>     userLogin = delegator.findByPrimaryKey("UserLogin",UtilMisc.toMap("userLoginId","admin"));
>>> } catch(e) {
>>>         Debug.logError(e,"");
>>> }
>>>
>>> * all the retrieval logic (scripts) is inlined with layout definition and this is something we try to avoid in all the existing screens
>>> * entity list iterators are not properly closed
>>> * some of the widget based financial reports have been converted to Birt: their layout is still very simple and comparable to the widget based versions available before Birt; so the conversion to Birt added a dependencies on this component without adding real value (the rptdesign files mix together data preparation scripts and ui definitions and in order to maintain them you have to use the Birt designer); also some of them are now broken: Income Stetements, Balance Sheet etc... This is probably caused by the recent refactoring of JSR-223 but the original widget based PDF are still there and are working fine...
>>> * building a report with this Birt integration still requires a lot of development work (similar to the one required to create a screen); but then the code in the rptdesign is very difficult to maintain without the editor
>>>
>>> My questions are:
>>> * do you really think that this way of integrating rptdesign reports is the answer to fill the gap of a good reporting tool in OFBiz? Are you actually using this integration for your reports?
>>> * do we all agree to make this Birt integration the best practice mechanism for all OFBiz reports?
>>> * do you really think that we should replace all the existing widget generated reports and FOP reports with rptdesign reports built using the existing Birt integration under the framework?
>>>
>>> If any of your answers will be "no" then in my opinion it would be much better to:
>>> 1) make Birt integration an optional component, downloaded separately
>>> 2) move the existing rptdesign reports out of the applications and keep them in the external Birt component
>>> 3) at this point users will have the option to use the Birt component or not, but the ootb code will be clean and without dependencies on it; most of all, we will not deliver reports that looks similar (ugly) but they are implemented randomly with Birt or Widgets
>>> 4) start evaluating, as a community, what should be the best practices for ootb reports: what is the tool we want, what are the minimal requirements etc... and then work together to get it in place and then migrate all existing reports to it in order to have a consistent system; if the community will not be able to reach a consensus on this, then we should leave the decision about the reporting tool to use to the end user
>>>
>>> I think that the Birt integration is a nice optional component, and I see that there may be interested parties, but in its current status it is not something ready for becoming the primary reporting tool for the ootb applications.
>>>
>>> Jacopo
>>
>>