[jira] [Resolved] (OFBIZ-2486) Next button/link on Physical Inventory Screen does not work
[ https://issues.apache.org/jira/browse/OFBIZ-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacopo Cappellato resolved OFBIZ-2486. -- Resolution: Won't Fix The release branch 4.0 is no more actively maintained. > Next button/link on Physical Inventory Screen does not work > --- > > Key: OFBIZ-2486 > URL: https://issues.apache.org/jira/browse/OFBIZ-2486 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: Release 4.0 > Environment: Sql Server 2005 >Reporter: Brian Sanders > Fix For: Release Branch 4.0 > > > To reproduce (requires > 100 inventory items, which should already be there): > Goto Facility > WebStoreWarehouse > Physical Inventory > Input "%" as the product id > Scroll to the bottom and click Next > The problem is that the facilityId is in the query string 2 times which > yields the following query on SQL Server 2005: > SELECT > PR.FACILITY_ID, II.COMMENTS, PR.PRODUCT_ID, PR.PRODUCT_TYPE_ID, > PR.PRIMARY_PRODUCT_CATEGORY_ID, PR.MANUFACTURER_PARTY_ID, > PR.INTRODUCTION_DATE, PR.SUPPORT_DISCONTINUATION_DATE, > PR.SALES_DISCONTINUATION_DATE, PR.SALES_DISC_WHEN_NOT_AVAIL, > PR.INTERNAL_NAME, PR.BRAND_NAME, PR.COMMENTS, PR.PRODUCT_NAME, > PR.DESCRIPTION, PR.LONG_DESCRIPTION, PR.PRICE_DETAIL_TEXT, > PR.SMALL_IMAGE_URL, PR.MEDIUM_IMAGE_URL, PR.LARGE_IMAGE_URL, > PR.DETAIL_IMAGE_URL, PR.DETAIL_SCREEN, PR.INVENTORY_MESSAGE, > PR.REQUIRE_INVENTORY, PR.QUANTITY_UOM_ID, PR.QUANTITY_INCLUDED, > PR.PIECES_INCLUDED, PR.REQUIRE_AMOUNT, PR.FIXED_AMOUNT, > PR.AMOUNT_UOM_TYPE_ID, PR.WEIGHT_UOM_ID, PR.WEIGHT, PR.HEIGHT_UOM_ID, > PR.PRODUCT_HEIGHT, PR.SHIPPING_HEIGHT, PR.WIDTH_UOM_ID, PR.PRODUCT_WIDTH, > PR.SHIPPING_WIDTH, PR.DEPTH_UOM_ID, PR.PRODUCT_DEPTH, PR.SHIPPING_DEPTH, > PR.PRODUCT_RATING, PR.RATING_TYPE_ENUM, PR.RETURNABLE, PR.TAXABLE, > PR.TAX_CATEGORY, PR.TAX_VAT_CODE, PR.TAX_DUTY_CODE, PR.CHARGE_SHIPPING, > PR.AUTO_CREATE_KEYWORDS, PR.INCLUDE_IN_PROMOTIONS, PR.IS_VIRTUAL, > PR.IS_VARIANT, PR.ORIGIN_GEO_ID, PR.REQUIREMENT_METHOD_ENUM_ID, > PR.BILL_OF_MATERIAL_LEVEL, PR.RESERV_MAX_PERSONS, PR.RESERV2ND_P_P_PERC, > PR.RESERV_NTH_P_P_PERC, PR.CREATED_DATE, PR.CREATED_BY_USER_LOGIN, > PR.LAST_MODIFIED_DATE, PR.LAST_MODIFIED_BY_USER_LOGIN, PR.IN_SHIPPING_BOX, > II.INVENTORY_ITEM_ID, II.INVENTORY_ITEM_TYPE_ID, II.PARTY_ID, > II.OWNER_PARTY_ID, II.STATUS_ID, II.DATETIME_RECEIVED, > II.DATETIME_MANUFACTURED, II.EXPIRE_DATE, II.FACILITY_ID, II.CONTAINER_ID, > II.LOT_ID, II.UOM_ID, II.BIN_NUMBER, II.LOCATION_SEQ_ID, > II.QUANTITY_ON_HAND_TOTAL, II.AVAILABLE_TO_PROMISE_TOTAL, > II.QUANTITY_ON_HAND, II.AVAILABLE_TO_PROMISE, II.SERIAL_NUMBER, > II.SOFT_IDENTIFIER, II.ACTIVATION_NUMBER, II.ACTIVATION_VALID_THRU, > II.UNIT_COST, II.CURRENCY_UOM_ID > FROM dbo.PRODUCT PR > INNER JOIN dbo.INVENTORY_ITEM II ON PR.PRODUCT_ID = II.PRODUCT_ID > WHERE (II.FACILITY_ID = ( @P0, @P1 ) AND II.INVENTORY_ITEM_TYPE_ID = @P2 AND > PR.PRODUCT_ID LIKE @P3) > ORDER BY PR.PRODUCT_ID ASC > II.FACILITY_ID = ( @P0, @P1 ) is not valid SQL syntax > I tested for the bug in 9.04 and it is not there. If I modify the URL by > removing the redundant facilityId, it works. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OFBIZ-3769) Entry of invoice in Trail balance after receiving PO
[ https://issues.apache.org/jira/browse/OFBIZ-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacopo Cappellato resolved OFBIZ-3769. -- Resolution: Won't Fix The release branch 4.0 is no more actively maintained. > Entry of invoice in Trail balance after receiving PO > > > Key: OFBIZ-3769 > URL: https://issues.apache.org/jira/browse/OFBIZ-3769 > Project: OFBiz > Issue Type: New Feature > Components: accounting >Affects Versions: Release 4.0 > Environment: windows xp >Reporter: Anurag > Fix For: Release Branch 4.0 > > Original Estimate: 48h > Remaining Estimate: 48h > > I have a problem with ofbiz-4.0 for entry of invoice in Trail balance after > receiving PO while it is working fine with ofbiz 9.0 after configure the > financial account to party group but not with ofbiz-4.0 after making the same > configuration . > could any one tell me there is any other configuration also required in > ofbiz-4.0. > or can i implement any patch in ofbiz4.0 for solving this problem. > Regards > Anurag Walia -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OFBIZ-4366) Accessing Ofbiz Entity UtilCache is time consuming
[ https://issues.apache.org/jira/browse/OFBIZ-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacopo Cappellato resolved OFBIZ-4366. -- Resolution: Won't Fix The release branch 4.0 is no more actively maintained. > Accessing Ofbiz Entity UtilCache is time consuming > -- > > Key: OFBIZ-4366 > URL: https://issues.apache.org/jira/browse/OFBIZ-4366 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release 4.0 > Environment: Producttion Environment Issue. In one particular > request, we are accessing UtilCache object 200 times via Generic Delegator, > findByConditionCache and findCache methods to read entity values. >Reporter: Arun Kumar Sri >Assignee: Jacques Le Roux > Labels: api-change > Fix For: Release Branch 4.0 > > Original Estimate: 0.05h > Remaining Estimate: 0.05h > > Its have been found that it is taking 3 to 4 seconds only for that. Is this > some thing that how is built or ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OFBIZ-1745) gift card processer error
[
https://issues.apache.org/jira/browse/OFBIZ-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacopo Cappellato resolved OFBIZ-1745.
--
Resolution: Won't Fix
The release branch 4.0 is no more actively maintained.
> gift card processer error
> -
>
> Key: OFBIZ-1745
> URL: https://issues.apache.org/jira/browse/OFBIZ-1745
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
>Affects Versions: Release 4.0
> Environment: windows
>Reporter: bj_zhou
> Fix For: Release Branch 4.0
>
>
> 2008-04-10 00:57:53,843 (http-0.0.0.0-8443-Processor3) [
> ModelService.java:481:ERROR] [ModelService.validate] : {ofbGcProcessor} :
> (IN) Required test error: org.ofbiz.service.ServiceValidationException: The
> following required parameter is missing:: [IN]
> [ofbGcProcessor.billToParty]The following required parameter is missing::
> [IN] [ofbGcProcessor.giftCard]The following required parameter is missing::
> [IN] [ofbGcProcessor.orderId]The following required parameter is missing::
> [IN] [ofbGcProcessor.orderItems]
> 2008-04-10 00:57:53,843 (http-0.0.0.0-8443-Processor3) [
> ServiceDispatcher.java:333:ERROR]
> exception report
> --
> Incoming context (in runSync : ofbGcProcessor) does not match expected
> requirements
> Exception: org.ofbiz.service.ServiceValidationException
> Message: The following required parameter is missing:: [IN]
> [ofbGcProcessor.billToParty]The following required parameter is missing::
> [IN] [ofbGcProcessor.giftCard]The following required parameter is missing::
> [IN] [ofbGcProcessor.orderId]The following required parameter is missing::
> [IN] [ofbGcProcessor.orderItems]
> stack trace
> ---
> org.ofbiz.service.ServiceValidationException: The following required
> parameter is missing:: [IN] [ofbGcProcessor.billToParty]The following
> required parameter is missing:: [IN] [ofbGcProcessor.giftCard]The following
> required parameter is missing:: [IN] [ofbGcProcessor.orderId]The following
> required parameter is missing:: [IN] [ofbGcProcessor.orderItems]
> org.ofbiz.service.ModelService.validate(ModelService.java:523)
> org.ofbiz.service.ModelService.validate(ModelService.java:478)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:331)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:166)
> org.ofbiz.accounting.payment.PaymentGatewayServices.capturePayment(PaymentGatewayServices.java:1541)
> org.ofbiz.accounting.payment.PaymentGatewayServices.capturePayment(PaymentGatewayServices.java:1447)
> org.ofbiz.accounting.payment.PaymentGatewayServices.captureOrderPayments(PaymentGatewayServices.java:1179)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:94)
> org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:56)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:347)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:152)
> org.ofbiz.accounting.payment.PaymentGatewayServices.capturePaymentsByInvoice(PaymentGatewayServices.java:986)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org.ofbiz.service.engine.StandardJavaEngine.serviceInvoker(StandardJavaEngine.java:94)
> org.ofbiz.service.engine.StandardJavaEngine.runSync(StandardJavaEngine.java:56)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:347)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:152)
> org.ofbiz.service.eca.ServiceEcaAction.runAction(ServiceEcaAction.java:113)
> org.ofbiz.service.eca.ServiceEcaRule.eval(ServiceEcaRule.java:141)
> org.ofbiz.service.eca.ServiceEcaUtil.evalRules(ServiceEcaUtil.java:158)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:463)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:214)
> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:152)
> org.ofbiz.order.order.OrderServices.checkDigitalItemFulfillment(O
[jira] [Closed] (OFBIZ-4735) User behaviour issue on Lookup.
[ https://issues.apache.org/jira/browse/OFBIZ-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4735. -- > User behaviour issue on Lookup. > --- > > Key: OFBIZ-4735 > URL: https://issues.apache.org/jira/browse/OFBIZ-4735 > Project: OFBiz > Issue Type: Bug > Components: framework >Reporter: Deepak Dixit >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: Release Branch 11.04, SVN trunk > > Attachments: OFBIZ-4735-11.04.patch, OFBIZ-4735.patch > > > Currently if user perform search or use pagination in lookup and if matches > found then list display but if no matches found then user didn't know that > result will come or not, even no matches found. > Change behaviour should be when user perform search or use pagination then > spinner (ajax loader image) shows wchich tells user that search is in > progress. > If matches found or not found spinner disappears. > Now user won't see any abnormal behaviour at ui. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - themes
Hi Mansour, From: "Mansour Al Akeel" Jacques, We use RTL. May be you are right about the the ease of use to find an item, but the user who has permission to all these functionality is an admin, and normally, she is comfortable finding any item quickly. The rest of the uses don't have that much items and menus shown. This makes sense for a deployment, not OOTB. It's IMO easier to select Flat Grey, if you prefer, for your deployments and to keep Tomahawk as OOTB default for the reasons I explained and others I add below. I know, other themes may look better, or fancier, but most users use flat gray to base their work on and extend/customize it, because it's easier and cleaner. I am not sure if bigger organization prefer fancier look and feel over cleaner. And to be honest, I think flat gray looks more professional than others. Therefore, it give a positive first impression, when demonstrated. Additional themes may still exist beside FlatGray, but I recommend to make it the default one. What makes you think "most users use flat gray to base their work" ? Could you define "easier and cleaner", and why Flat Grey is easier and cleaner (besides that it's the only one that is RTL which I understand for you is a must have) What makes you think Flat Grey looks more professionnal? For me Flat Gray has not enough contrast. In other words all looks grey/pale and it's difficult to spot things. With Tomahawk I quickly spot buttons, links, etc. because there is more contrast. Maybe it's If you read me, it's not about being fancier but ergonomic which is for me the only priority for the community to use OFBiz OOTB (contrary to deployments) Also I'd like to know why Flat Grey is the only Theme being marked as being Sight-Impaired Accessible? Adrian? I remember I began to add < On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux wrote: I see that most people prefer Flat Grey. Let me explain why I prefer Tomahawk. Did you ever wonder why the paper we write on has more than often a greater height than width, why newspaper have many columns, etc. Here is an answer http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns OK, my argument: don't you feel a pain to find an application, a menu entry in Flat Grey? No? Then you are used to find it at some place and don't care anymore. Now just imagine the same for a new user... This is where Tomahawk is better. It's far easier to find an entry in 2 colums (applications in Tomahawk) than in 7 columns (applications in Flat Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in Flat Grey). Just try it Another point: Product screens are awful in Flat Grey (to many buttons for menus, hard to spot). Though actually I believe Tomahawk would benefit from a third column, for instance for Product. This could be 2 twin columns if more than, say, 15 entries would show in a column. Like we have for Applications, though not sure how it's organized. I mean why some are in right column and other in left one? Also something wich could help spot entries quicker would be to allow sorting entries in menus by language. It's now only done based on English. OK, now there is the RTL feature. Who use it? Few I guess (http://en.wikipedia.org/wiki/Right-to-left http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does not diminish RTL importance, but ponders it in choice for a default theme. My 2 cts Jacques From: "Ashish Vijaywargiya" My vote will be to keep two themes in the project. IMO Flatgrey theme is the best to keep as the default one for the project. -- Ashish On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxmedia.com> wrote: > I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of > them to "Extras"; keep just one (or two) > Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. Jacopo
Re: Default package size assumed by fedex?
Fedex rates calculation requires weight and dimensions of packages only. Also Make sure that which type of rates you are getting, its a list rate or discounted rate of your account. Regards Arun Patidar Hotwax Media | www.hotwaxmedia.com On 20-Mar-2012, at 5:36 PM, Prince Sewani wrote: > Hi All, > > I've a question, If the 'shipment.fedex.default.packagingType' is set to > 'YOURPACKNG' , > then what are the default dimensions assumed by Fedex for the package in > which the > > product will be packed? > > I see a lot of difference in rates when I log-into Fedex a/c and give the zip > codes, the > > difference in rate still lies whether I provide the dimensions of the package > or not. > > Any pointers/clues will be of great help. > > Regards > Prince
[jira] [Commented] (OFBIZ-4734) User behaviour issue on auto-completer.
[ https://issues.apache.org/jira/browse/OFBIZ-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234069#comment-13234069 ] Deepak Dixit commented on OFBIZ-4734: - Thanks Ashish. > User behaviour issue on auto-completer. > --- > > Key: OFBIZ-4734 > URL: https://issues.apache.org/jira/browse/OFBIZ-4734 > Project: OFBiz > Issue Type: Bug >Reporter: Deepak Dixit >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: Release Branch 11.04, SVN trunk > > Attachments: OFBIZ-4734-Release11.04.patch, OFBIZ-4734-Trunk.patch > > > Currently if user type in auto-completer text box and if matches found then > list display as auto-completer result list but if no matches found then user > didn't know that result will come or not, even no matches found. > Change behaviour is when user type in text box then spinner (ajax loader > image) shows wchich tells user that search is in progress. > If matches found or not found spinner disapperars and reult/ no result > message listed in auto-completer relsult list. > Now user won't see any abnormal behaviour at ui. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4735) User behaviour issue on Lookup.
[ https://issues.apache.org/jira/browse/OFBIZ-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234070#comment-13234070 ] Deepak Dixit commented on OFBIZ-4735: - Thanks Ashish. > User behaviour issue on Lookup. > --- > > Key: OFBIZ-4735 > URL: https://issues.apache.org/jira/browse/OFBIZ-4735 > Project: OFBiz > Issue Type: Bug > Components: framework >Reporter: Deepak Dixit >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: Release Branch 11.04, SVN trunk > > Attachments: OFBIZ-4735-11.04.patch, OFBIZ-4735.patch > > > Currently if user perform search or use pagination in lookup and if matches > found then list display but if no matches found then user didn't know that > result will come or not, even no matches found. > Change behaviour should be when user perform search or use pagination then > spinner (ajax loader image) shows wchich tells user that search is in > progress. > If matches found or not found spinner disappears. > Now user won't see any abnormal behaviour at ui. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - example, exampleext
From: "Mansour Al Akeel" 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 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
Re: Lose Weight Program for OFBiz - themes
Jacques, We use RTL. May be you are right about the the ease of use to find an item, but the user who has permission to all these functionality is an admin, and normally, she is comfortable finding any item quickly. The rest of the uses don't have that much items and menus shown. I know, other themes may look better, or fancier, but most users use flat gray to base their work on and extend/customize it, because it's easier and cleaner. I am not sure if bigger organization prefer fancier look and feel over cleaner. And to be honest, I think flat gray looks more professional than others. Therefore, it give a positive first impression, when demonstrated. Additional themes may still exist beside FlatGray, but I recommend to make it the default one. On Tue, Mar 20, 2012 at 6:10 PM, Jacques Le Roux wrote: > I see that most people prefer Flat Grey. > > Let me explain why I prefer Tomahawk. > > Did you ever wonder why the paper we write on has more than often a greater > height than width, why newspaper have many columns, etc. > Here is an answer > http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns > > OK, my argument: don't you feel a pain to find an application, a menu entry > in Flat Grey? No? Then you are used to find it at some place and don't care > anymore. Now just imagine the same for a new user... > > This is where Tomahawk is better. It's far easier to find an entry in 2 > colums (applications in Tomahawk) than in 7 columns (applications in Flat > Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in > Flat Grey). Just try it > > Another point: Product screens are awful in Flat Grey (to many buttons for > menus, hard to spot). Though actually I believe Tomahawk would benefit from > a third column, for instance for Product. This could be 2 twin columns if > more than, say, 15 entries would show in a column. Like we have for > Applications, though not sure how it's organized. I mean why some are in > right column and other in left one? Also something wich could help spot > entries quicker would be to allow sorting entries in menus by language. It's > now only done based on English. > > OK, now there is the RTL feature. Who use it? Few I guess > (http://en.wikipedia.org/wiki/Right-to-left > http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does not > diminish RTL importance, but ponders it in choice for a default theme. > > My 2 cts > > Jacques > > > From: "Ashish Vijaywargiya" > >> My vote will be to keep two themes in the project. IMO Flatgrey theme is >> the best to keep as the default one for the project. >> >> -- >> Ashish >> >> On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato < >> jacopo.cappell...@hotwaxmedia.com> wrote: >> >>> > I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of >>> > them >>> to "Extras"; keep just one (or two) >>> > >>> >>> Jacques proposed to keep Tomahawk (default) and Flat Grey. >>> Olivier proposed to keep just one (Tomahawk, I guess). >>> No other comments so far. >>> What should be do with the remaining themes? Attic or Extras? Are there >>> volunteers for Extras? I would suggest that, if we move them to Extras we >>> create *one* project only (for all the themes) rather than one project >>> for >>> theme... but I would love to get your feedback on this. >>> >>> Jacopo >> >> >
[jira] [Commented] (OFBIZ-4740) Un-necessary Drop Down in Web Tools
[ https://issues.apache.org/jira/browse/OFBIZ-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233902#comment-13233902 ] Jacques Le Roux commented on OFBIZ-4740: We should check before if it's not a feature which dissapeared (for a reason or another, but not wanted). > Un-necessary Drop Down in Web Tools > --- > > Key: OFBIZ-4740 > URL: https://issues.apache.org/jira/browse/OFBIZ-4740 > Project: OFBiz > Issue Type: Improvement > Components: framework >Reporter: Tom Burns >Priority: Trivial > > Drop down in Web Tools Main select Service Reference appears to do nothing > useful. > To reproduce: > In Web Tools Main select Service Reference > To the right of the alpha list select a Dispatcher from the drop down. > Expected: Expected results unknown > Actual: Service Reference is refreshed with all services -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4741) Error in Find Content Lookup
Error in Find Content Lookup Key: OFBIZ-4741 URL: https://issues.apache.org/jira/browse/OFBIZ-4741 Project: OFBiz Issue Type: Bug Components: content Affects Versions: SVN trunk Reporter: Tom Burns Priority: Minor To reproduce: In Content Manager select Content (https://demo-trunk.ofbiz.apache.org/content/control/findContent) Click Lookup Icon for Locale String Expected: Lookup Locale dialog Actual: Error message org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen [component://common/widget/CommonScreens.xml#LookupDecorator]: java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to java.util.Locale (java.util.LinkedHashMap cannot be cast to java.util.Locale) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - ofbizwebsite
From: "Scott Gray" On 21/03/2012, at 9:24 AM, Erwan de FERRIERES wrote: Le 20/03/2012 12:48, Jacopo Cappellato a écrit : G) specialpurpose/ofbizwebsite: move to "Attic" Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo What is missing on this component ? I think we should keep it where it is, but like for JCR, write a small roadmap on what we need. The website is somehow dependent from JCR, if we implement it completely. -- Erwan de FERRIERES www.nereide.biz What possible benefit does this component offer to our users? It's nothing more than a ridiculously large example component. If we were going to keep this in OFBiz we'd need a new component folder, maybe "extremelyspecialpurpose" or perhaps "notreallyanypurpose". +1 for moving to extras if there are any volunteers to maintain it otherwise, +1 for the attic. (This is essentially my vote for all the special purpose apps except ecommerce) This sounds like a wise/experienced suggestion Jacques Regards Scott
Re: Lose Weight Program for OFBiz - themes
I see that most people prefer Flat Grey. Let me explain why I prefer Tomahawk. Did you ever wonder why the paper we write on has more than often a greater height than width, why newspaper have many columns, etc. Here is an answer http://graphicdesign.stackexchange.com/questions/3553/why-do-newspapers-use-multiple-columns OK, my argument: don't you feel a pain to find an application, a menu entry in Flat Grey? No? Then you are used to find it at some place and don't care anymore. Now just imagine the same for a new user... This is where Tomahawk is better. It's far easier to find an entry in 2 colums (applications in Tomahawk) than in 7 columns (applications in Flat Grey). Or an entry in an application (1 column for Tomahawk, up to 14 in Flat Grey). Just try it Another point: Product screens are awful in Flat Grey (to many buttons for menus, hard to spot). Though actually I believe Tomahawk would benefit from a third column, for instance for Product. This could be 2 twin columns if more than, say, 15 entries would show in a column. Like we have for Applications, though not sure how it's organized. I mean why some are in right column and other in left one? Also something wich could help spot entries quicker would be to allow sorting entries in menus by language. It's now only done based on English. OK, now there is the RTL feature. Who use it? Few I guess (http://en.wikipedia.org/wiki/Right-to-left http://en.wikipedia.org/wiki/Left-to-right#Directionality). Which does not diminish RTL importance, but ponders it in choice for a default theme. My 2 cts Jacques From: "Ashish Vijaywargiya" My vote will be to keep two themes in the project. IMO Flatgrey theme is the best to keep as the default one for the project. -- Ashish On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxmedia.com> wrote: > I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two) > Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. Jacopo
[jira] [Commented] (OFBIZ-4740) Un-necessary Drop Down in Web Tools
[ https://issues.apache.org/jira/browse/OFBIZ-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233819#comment-13233819 ] Tom Burns commented on OFBIZ-4740: -- Consider removing this drop down > Un-necessary Drop Down in Web Tools > --- > > Key: OFBIZ-4740 > URL: https://issues.apache.org/jira/browse/OFBIZ-4740 > Project: OFBiz > Issue Type: Improvement > Components: framework >Reporter: Tom Burns >Priority: Trivial > > Drop down in Web Tools Main select Service Reference appears to do nothing > useful. > To reproduce: > In Web Tools Main select Service Reference > To the right of the alpha list select a Dispatcher from the drop down. > Expected: Expected results unknown > Actual: Service Reference is refreshed with all services -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OFBIZ-4740) Un-necessary Drop Down in Web Tools
Un-necessary Drop Down in Web Tools --- Key: OFBIZ-4740 URL: https://issues.apache.org/jira/browse/OFBIZ-4740 Project: OFBiz Issue Type: Improvement Components: framework Reporter: Tom Burns Priority: Trivial Drop down in Web Tools Main select Service Reference appears to do nothing useful. To reproduce: In Web Tools Main select Service Reference To the right of the alpha list select a Dispatcher from the drop down. Expected: Expected results unknown Actual: Service Reference is refreshed with all services -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - example, exampleext
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. On Tue, Mar 20, 2012 at 4:33 PM, Erwan de FERRIERES 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
[jira] [Created] (OFBIZ-4739) View Calendar Broken in Party Manager > Relationships
View Calendar Broken in Party Manager > Relationships - Key: OFBIZ-4739 URL: https://issues.apache.org/jira/browse/OFBIZ-4739 Project: OFBiz Issue Type: Bug Components: party Affects Versions: SVN trunk Reporter: Tom Burns Priority: Minor To reproduce: Lookup a party in Party Manager say "Company" Click Relationships Tab In the Relationships section click the Calendar icon (ListPartyRelationships ) Expected: Calendar to pop up Actual: Nothing -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - ofbizwebsite
On 21/03/2012, at 9:24 AM, Erwan de FERRIERES wrote: > Le 20/03/2012 12:48, Jacopo Cappellato a écrit : >> >>> G) specialpurpose/ofbizwebsite: move to "Attic" >>> >> >> Jacques and Olivier proposed to move it to Extras instead just in case >> someone will pick up the work and complete it in the future. >> I would like to mention that, if the original goal was "to eat our own dog >> food" and run the OFBiz site on it, then this could be in contrast with the >> ASF infrastructure offered to the projects. >> >> Jacopo > What is missing on this component ? > I think we should keep it where it is, but like for JCR, write a small > roadmap on what we need. The website is somehow dependent from JCR, if we > implement it completely. > > -- > Erwan de FERRIERES > www.nereide.biz What possible benefit does this component offer to our users? It's nothing more than a ridiculously large example component. If we were going to keep this in OFBiz we'd need a new component folder, maybe "extremelyspecialpurpose" or perhaps "notreallyanypurpose". +1 for moving to extras if there are any volunteers to maintain it otherwise, +1 for the attic. (This is essentially my vote for all the special purpose apps except ecommerce) Regards Scott
Re: Lose Weight Program for OFBiz - example, exampleext
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
[jira] [Commented] (OFBIZ-4731) Error in ListFindAcctgTransEntriesByAccount
[ https://issues.apache.org/jira/browse/OFBIZ-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233716#comment-13233716 ] Tom Burns commented on OFBIZ-4731: -- The note in the discussion section "Problem In Trunk and 10.04 OK in 9.0" is not correct, this issue is not a problem in 10.04. > Error in ListFindAcctgTransEntriesByAccount > --- > > Key: OFBIZ-4731 > URL: https://issues.apache.org/jira/browse/OFBIZ-4731 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: Release Branch 10.04, SVN trunk >Reporter: Tom Burns >Assignee: Jacopo Cappellato >Priority: Minor > Attachments: AfterPatch.bmp, BeforePatch.bmp, GlForms.xml.patch > > > Problem In Trunk and 10.04 OK in 9.04 > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://common/widget/CommonScreens.xml#GlobalDecorator]: > java.lang.IllegalArgumentException: Return value from use-when condition eval > was not a Boolean: null [null] on the field glAccountId of form > ListFindAcctgTransEntriesByAccount (Return value from use-when condition eval > was not a Boolean: null [null] on the field glAccountId of form > ListFindAcctgTransEntriesByAccount) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - ofbizwebsite
Le 20/03/2012 12:48, Jacopo Cappellato a écrit : G) specialpurpose/ofbizwebsite: move to "Attic" Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo What is missing on this component ? I think we should keep it where it is, but like for JCR, write a small roadmap on what we need. The website is somehow dependent from JCR, if we implement it completely. -- Erwan de FERRIERES www.nereide.biz
Re: Lose Weight Program for OFBiz JCR function
Le 20/03/2012 13:18, Sascha Rodekamp a écrit : Hi, 1) keep it in framework +1 2) but remove it from the upcoming new release branch 12.04 +1 - for now the JCR implementation provide the the developer an API which helps to create, read, update or delete content in the repository. We have no integration in other (i.e. the content) applications. So there is no problem to keep the jcr implementation out of release 12.04. 3) and then, as a community, we could start the effort +1 - that was the intention of the Jira Task OFBIZ-4659. There is a lot work to do. I like the idea having a roadmap, that could possibly speed up the development and let people focus on certain features... Thanks and regards, Sascha Works for me. -- Erwan de FERRIERES www.nereide.biz
Re: Lose Weight Program for OFBiz - guiapp and pos
I'm in favor of moving all special purpose apps to Extras (or Attic for some of the older/unused ones) except for ecommerce. Even then the only reason I'd like to keep ecommerce is because it is the only special purpose app that is almost universally useful to OFBiz users and I'd like to keep it under our control for now at least. So I'd like to see pos moved to Extras and perhaps these users of it can step up and help maintain it. Regards Scott On 21/03/2012, at 4:21 AM, Jacopo Cappellato wrote: > Makes sense > > Jacopo > > On Mar 20, 2012, at 3:58 PM, Jacques Le Roux wrote: > >> From: "Jacopo Cappellato" A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to "Extras" >>> >>> No one objected so far; Jacques offered his help for #A. >>> Should we focus on #A for now (it is an actionable item) and then discuss >>> #B also based on the outcome of similar discussions for other >>> specialpurpose components? >> >> Yes, I know there are POS users out there. So I now wonder if we should not >> wait before moving it out of specialpurpose. When you think about it, it's >> the twin of eCommerce. With a bit more involvment though, mostly because of >> its relation with Entity Sync (maintenance) which is actually part of the >> framework (entityext component). >> >> Jacques >
Re: Default package size assumed by fedex?
We currently use the new FedEx Web Services API in our OFBiz installation. We'll try to create a patch and contribute it fairly soon. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Default-package-size-assumed-by-fedex-tp4488552p4489853.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] [Created] (OFBIZ-4738) Minor Refactoring in CategoryWorker - use delegator instead of request in getRelatedCategoriesRet
Minor Refactoring in CategoryWorker - use delegator instead of request in getRelatedCategoriesRet - Key: OFBIZ-4738 URL: https://issues.apache.org/jira/browse/OFBIZ-4738 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: SVN trunk Reporter: Markus M. May Priority: Trivial Fix For: SVN trunk The method getRelatedCategoriesRet uses the request, the final called method could be called using the delegator directly easily. I have refactored the method accordingly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: loop code simplification
I think it's really necessary to look at the bigger picture rather than
worrying about having a null check in place. The delegator methods that return
a List pretty much never return null, so the only time that specific list will
be null is when an EntityException is thrown. So IMO the main problem with the
methods in ContactMechWorker are that they silently (aside from logging) absorb
those exceptions and then try to carry on as if nothing went wrong.
IMO those methods should probably have a 'throws EntityException' declaration
added and then all the catch blocks and list != null checks
removed. There is so much wrong in that class though, it could do with plenty
of other work as well.
Regards
Scott
On 21/03/2012, at 4:24 AM, Erwan de FERRIERES wrote:
> 2012/3/20 Jacques Le Roux :
>> BTW, this shows how stupid is the for loop in Java implementation. The
>> suggested safeList() should be handled by the compiler IMO, I
>> see no gains to not have it in but to get NPEs. Did I miss something?
>>
> Nothing. Is there an implementation of this safeList() in commons ?
>
> I think I will keep the while as they are, and work only on those
> which only have the .hasNext().
>
> Thanks for your comments !
>
>> Jacques
>>
>> From: "Paul Foxworthy"
>>
>>> Hi Erwan,
>>>
>>> To be sure there is no Null Pointer Exception, yes, you need to test for
>>> null first. One possibility is to just let the NPE happen.
>>>
>>> The discussion at
>>>
>>> http://stackoverflow.com/questions/2250031/null-check-in-an-enhanced-for-loop
>>>
>>> suggests
>>>
>>> for( Object o : safe( list ) ) {
>>> // do whatever
>>> }
>>>
>>> Where safe would be:
>>>
>>> public static List safe( List other ) {
>>> return other == null ? Collections.EMPTY_LIST : other;
>>> }
>>>
>>> Cleaner code. I suspect the method would be inlined by most Java
>>> compilers.
>>>
>>> Cheers
>>>
>>> Paul Foxworthy
>>>
>>>
>>> Erwan de FERRIERES-3 wrote
Hi,
I'm trying to remove a lot of iterators, and use the for-each syntax,
which exists since java 1.5.
During my journey, I found a lot of double tests for a while like this
one:
while (typePurposes != null && typePurposes.hasNext()) {
(ContactMechWorker.java line 606)
Can it be simplified to for(GenericValue contactMechTypePurpose :
theList) ? Or should I keep it like it is ?
Regards,
--
Erwan de FERRIERES
www.nereide.biz
>>>
>>> -
>>> --
>>> Coherent Software Australia Pty Ltd
>>> http://www.cohsoft.com.au/
>>>
>>> Bonsai ERP, the all-inclusive ERP system
>>> http://www.bonsaierp.com.au/
>>>
>>> --
>>> View this message in context:
>>> http://ofbiz.135035.n4.nabble.com/loop-code-simplification-tp4487741p4488324.html
>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
>
>
> --
> Erwan de FERRIERES
Re: Lose Weight Program for OFBiz - themes
My vote will be to keep two themes in the project. IMO Flatgrey theme is the best to keep as the default one for the project. -- Ashish On Tue, Mar 20, 2012 at 5:18 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxmedia.com> wrote: > > I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them > to "Extras"; keep just one (or two) > > > > Jacques proposed to keep Tomahawk (default) and Flat Grey. > Olivier proposed to keep just one (Tomahawk, I guess). > No other comments so far. > What should be do with the remaining themes? Attic or Extras? Are there > volunteers for Extras? I would suggest that, if we move them to Extras we > create *one* project only (for all the themes) rather than one project for > theme... but I would love to get your feedback on this. > > Jacopo
Re: Lose Weight Program for OFBiz - themes
Another data point: I've been in several OFBiz shops recently and have observed that many people end up using Flat Grey. Not sure why this is. IMHO Tomahawk looks nice, but in the end, the mixture of dark and light is hard on the eyes. Having to scroll over to expose links makes navigation more cumbersome. The hierarchical features are really nice, but if you have to hunt around to find them, it diminishes their appeal. This is just my opinion and the reason I always end up using Flat Grey. Best Regards, Ruth Hoffman On 3/20/12 12:36 PM, Anil Patel wrote: I prefer keep Flat Gray theme in Ofbiz over others. Thanks and Regards Anil Patel On Mar 20, 2012, at 9:18 AM, Jacques Le Roux wrote: From: "Mansour Al Akeel" Flat Gray is simple, and clear. It serves well as a basic theme. AFAIK, it the only theme that supports both directions for languages LTR and RTL. Right and Tomahawk is the last evolution of all others. I prefer Tomahawk: it's easier to find you way because of hierarchised menus (with only 2 levels). Flat Gray is a must have because of LTR and RTL (thanks Adrian!) One project for all themes in Extra makes sense to me. Some/all? (all but Bizzness are pre-evolutions of Tomahawk) could go in Attic (I never got to use Bizzness), to be voted... Jacques On Tue, Mar 20, 2012 at 10:33 AM, wrote: My preference is to keep Flat Grey and one other theme - I have no preference on what that other theme is. -Adrian Quoting Jacopo Cappellato: I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two) Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. Jacopo
Re: Lose Weight Program for OFBiz - example, exampleext
I use example component as my reference for best practice guide. Still I think its better placed in Ofbiz Extras. Thanks and Regards Anil Patel HotWax Media Inc On Mar 20, 2012, at 10:17 AM, Nicolas Malin wrote: > Le 20/03/2012 16:38, Jacques Le Roux a écrit : >> From: "Nicolas Malin" >>> 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 >>> example and exampleext are they useful for production site ? >>> if Apache OFBiz implement a plugin manager, why don't use ant (or other) to >>> prepare OFBiz according to its use. >>> >>> If you want develop on OFBiz, when you download from svn run : ant >>> run-install-dev (it's a example ;)) and ant use plugin manager >>> to resolve all extras project that compose the official OFBiz developer >>> package. >> >> Interesting, it's based on Ivy, right? > In my mind yes, but I set an idea not a solution ;) >> Did you ever re-consider Maven (I know the historical ;o)? >> I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven >> during a Geronimo developement > I prefer ant + ivy too > >> >>> [my life] >>> At this time, I comment all unneeded components as example on production >>> site. It isn't a problem, just I don't find clean :) >>> [/my life] >> >> Yes, I do the same, and certainly others as well... >> >> Jacques >> >> >>> -- >>> Nicolas MALIN >>> Consultant >>> Tél : 06.17.66.40.06 >>> Site projet : http://www.neogia.org/ >>> --- >>> Société LibrenBerry >>> Tél : 02.48.02.56.12 >>> Site : http://www.librenberry.net/ >>> > > > -- > Nicolas MALIN > Consultant > Tél : 06.17.66.40.06 > Site projet : http://www.neogia.org/ > --- > Société LibrenBerry > Tél : 02.48.02.56.12 > Site : http://www.librenberry.net/ >
Re: Lose Weight Program for OFBiz - themes
I prefer keep Flat Gray theme in Ofbiz over others. Thanks and Regards Anil Patel On Mar 20, 2012, at 9:18 AM, Jacques Le Roux wrote: > From: "Mansour Al Akeel" >> Flat Gray is simple, and clear. >> It serves well as a basic theme. >> AFAIK, it the only theme that supports both directions for languages >> LTR and RTL. > > Right and Tomahawk is the last evolution of all others. I prefer Tomahawk: > it's easier to find you way because of hierarchised menus (with only 2 > levels). > Flat Gray is a must have because of LTR and RTL (thanks Adrian!) > > One project for all themes in Extra makes sense to me. > Some/all? (all but Bizzness are pre-evolutions of Tomahawk) could go in Attic > (I never got to use Bizzness), to be voted... > > Jacques > >> >> On Tue, Mar 20, 2012 at 10:33 AM, >> wrote: >>> My preference is to keep Flat Grey and one other theme - I have no >>> preference on what that other theme is. >>> >>> -Adrian >>> >>> >>> Quoting Jacopo Cappellato : >>> > I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them > to "Extras"; keep just one (or two) > Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. Jacopo >>> >>> >>>
Re: Lose Weight Program for OFBiz - example, exampleext
Le 20/03/2012 16:38, Jacques Le Roux a écrit : From: "Nicolas Malin" 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 example and exampleext are they useful for production site ? if Apache OFBiz implement a plugin manager, why don't use ant (or other) to prepare OFBiz according to its use. If you want develop on OFBiz, when you download from svn run : ant run-install-dev (it's a example ;)) and ant use plugin manager to resolve all extras project that compose the official OFBiz developer package. Interesting, it's based on Ivy, right? In my mind yes, but I set an idea not a solution ;) Did you ever re-consider Maven (I know the historical ;o)? I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven during a Geronimo developement I prefer ant + ivy too [my life] At this time, I comment all unneeded components as example on production site. It isn't a problem, just I don't find clean :) [/my life] Yes, I do the same, and certainly others as well... Jacques -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/ -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz - example, exampleext
I did not intend to use Maven at all, but good catch and yes for a (possible far) future iteration Jacques From: "Mansour Al Akeel" Ant+Ivy would fit easier with the structure of ofbiz components. If we want to move to maven, then a modification to org/ofbiz/base/location/FlexibleLocation.java has to be done to allow loading resource from a jar file. I am assuming with maven, you want to package the whole component in a jar file. I think this is good idea, and it will have to done for OSGI anyway. But for the moment, I think Ant+Ivy are more suitable. On Tue, Mar 20, 2012 at 11:38 AM, Jacques Le Roux wrote: From: "Nicolas Malin" 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 example and exampleext are they useful for production site ? if Apache OFBiz implement a plugin manager, why don't use ant (or other) to prepare OFBiz according to its use. If you want develop on OFBiz, when you download from svn run : ant run-install-dev (it's a example ;)) and ant use plugin manager to resolve all extras project that compose the official OFBiz developer package. Interesting, it's based on Ivy, right? Did you ever re-consider Maven (I know the historical ;o)? I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven during a Geronimo developement [my life] At this time, I comment all unneeded components as example on production site. It isn't a problem, just I don't find clean :) [/my life] Yes, I do the same, and certainly others as well... Jacques -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty
You could maybe contribute your work on it? Jacques From: "J. Eckard" I currently use jetty, and keep it updated internally to track the jetty 6 codebase. I have no problem with it being removed from the framework, as long as we don't assume or require tomcat in the future. On Mar 20, 2012, at 7:48 AM, Jacopo Cappellato wrote: C) $OFBIZ_HOME/debian: move to "Attic" D) the seleniumxml code in framework/testtools: move to "Attic" E) specialpurpose/workflow: move to "Attic" F) specialpurpose/shark: move to "Attic" J) framework/appserver: move to "Extras" K) framework/jetty: move to "Extras" (or "Attic") The above are components/features that don't seem to be used/maintained by the community: some of them are very old (workflow, shark, appserver, jetty), some of them are experimental (shark, seleniumxml), some of them are very specialized (debian). I have proposed some of them for the Attic and some of them for the Extras but in theory all of them could go to Extras if we find at least one maintainer for each; if not, each of them could go to Attic. Any ideas? volunteers (OFBiz committers or not)? No one objected or commented on them so far (so I suspect that there could be a lazy consensus); for the seleniumxml code there was also a thread some weeks ago in the user list where there seemed to be a general consensus (also from the original contributors of the work) for the removal (apart from Hans who is using it, it doesn't seem to be used much by the community). Jacopo
Re: Lose Weight Program for OFBiz - example, exampleext
Ant+Ivy would fit easier with the structure of ofbiz components. If we want to move to maven, then a modification to org/ofbiz/base/location/FlexibleLocation.java has to be done to allow loading resource from a jar file. I am assuming with maven, you want to package the whole component in a jar file. I think this is good idea, and it will have to done for OSGI anyway. But for the moment, I think Ant+Ivy are more suitable. On Tue, Mar 20, 2012 at 11:38 AM, Jacques Le Roux wrote: > From: "Nicolas Malin" > >> 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 >> >> example and exampleext are they useful for production site ? >> if Apache OFBiz implement a plugin manager, why don't use ant (or other) >> to prepare OFBiz according to its use. >> >> If you want develop on OFBiz, when you download from svn run : ant >> run-install-dev (it's a example ;)) and ant use plugin manager >> to resolve all extras project that compose the official OFBiz developer >> package. > > > Interesting, it's based on Ivy, right? Did you ever re-consider Maven (I > know the historical ;o)? > I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven > during a Geronimo developement > > >> [my life] >> At this time, I comment all unneeded components as example on production >> site. It isn't a problem, just I don't find clean :) >> [/my life] > > > Yes, I do the same, and certainly others as well... > > Jacques > > > >> -- >> Nicolas MALIN >> Consultant >> Tél : 06.17.66.40.06 >> Site projet : http://www.neogia.org/ >> --- >> Société LibrenBerry >> Tél : 02.48.02.56.12 >> Site : http://www.librenberry.net/ >> >
Re: Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty
I currently use jetty, and keep it updated internally to track the jetty 6 codebase. I have no problem with it being removed from the framework, as long as we don't assume or require tomcat in the future. On Mar 20, 2012, at 7:48 AM, Jacopo Cappellato wrote: > >> C) $OFBIZ_HOME/debian: move to "Attic" >> >> D) the seleniumxml code in framework/testtools: move to "Attic" >> >> E) specialpurpose/workflow: move to "Attic" >> >> F) specialpurpose/shark: move to "Attic" >> >> J) framework/appserver: move to "Extras" >> >> K) framework/jetty: move to "Extras" (or "Attic") > > The above are components/features that don't seem to be used/maintained by > the community: some of them are very old (workflow, shark, appserver, jetty), > some of them are experimental (shark, seleniumxml), some of them are very > specialized (debian). > I have proposed some of them for the Attic and some of them for the Extras > but in theory all of them could go to Extras if we find at least one > maintainer for each; if not, each of them could go to Attic. > Any ideas? volunteers (OFBiz committers or not)? > No one objected or commented on them so far (so I suspect that there could be > a lazy consensus); for the seleniumxml code there was also a thread some > weeks ago in the user list where there seemed to be a general consensus (also > from the original contributors of the work) for the removal (apart from Hans > who is using it, it doesn't seem to be used much by the community). > > Jacopo >
Re: Lose Weight Program for OFBiz - example, exampleext
From: "Nicolas Malin" 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 example and exampleext are they useful for production site ? if Apache OFBiz implement a plugin manager, why don't use ant (or other) to prepare OFBiz according to its use. If you want develop on OFBiz, when you download from svn run : ant run-install-dev (it's a example ;)) and ant use plugin manager to resolve all extras project that compose the official OFBiz developer package. Interesting, it's based on Ivy, right? Did you ever re-consider Maven (I know the historical ;o)? I guess ant+Ivy is more flexible? I prefer it too, but only crossed Maven during a Geronimo developement [my life] At this time, I comment all unneeded components as example on production site. It isn't a problem, just I don't find clean :) [/my life] Yes, I do the same, and certainly others as well... Jacques -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
From: "Nicolas Malin" Agree with Jacopo, specialpurpose should be on extras. Huho? ;o) Scrum depend of projectmgr, the OFBiz extra will be have a dependency management to ensure that all needed components will be present. Good point! To all: is crowd dependent on ldap? Jacques Nicolas Le 20/03/2012 12:47, Jacopo Cappellato a écrit : H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to "Extras" (if there are persons interested to become committers/maintainers) or to "Attic" There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the "exampleext" component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the "concept" of specialpurpose application is in general better suited for Apache Extras rather than for the OFBiz svn and releases. -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty
From: "Jacopo Cappellato" C) $OFBIZ_HOME/debian: move to "Attic" D) the seleniumxml code in framework/testtools: move to "Attic" E) specialpurpose/workflow: move to "Attic" F) specialpurpose/shark: move to "Attic" J) framework/appserver: move to "Extras" This one I could try to maintain. The others can move to Attic for me. But I must say that recently I was not able to follow/answer the recent demands after Tomcat evolution. So maybe in futur to Attic too, and could be resurrected later... Jacques K) framework/jetty: move to "Extras" (or "Attic") The above are components/features that don't seem to be used/maintained by the community: some of them are very old (workflow, shark, appserver, jetty), some of them are experimental (shark, seleniumxml), some of them are very specialized (debian). I have proposed some of them for the Attic and some of them for the Extras but in theory all of them could go to Extras if we find at least one maintainer for each; if not, each of them could go to Attic. Any ideas? volunteers (OFBiz committers or not)? No one objected or commented on them so far (so I suspect that there could be a lazy consensus); for the seleniumxml code there was also a thread some weeks ago in the user list where there seemed to be a general consensus (also from the original contributors of the work) for the removal (apart from Hans who is using it, it doesn't seem to be used much by the community). Jacopo
Re: Lose Weight Program for OFBiz - documents
From: "Jacopo Cappellato" O) framework/documents: move the content to Wiki and then move to "Attic" The broader topic is to move all the artifacts related to online help out of the framework; they should all live under "applications". What about documents currently in documents folders under framework folders? Some could be replaced by README, like FrameworkBase.xml. Not sure for stuff like ReceivingEmail.xml which speaks about MCA (same for other framework specific features) Jacques
Re: loop code simplification
2012/3/20 Jacques Le Roux :
> BTW, this shows how stupid is the for loop in Java implementation. The
> suggested safeList() should be handled by the compiler IMO, I
> see no gains to not have it in but to get NPEs. Did I miss something?
>
Nothing. Is there an implementation of this safeList() in commons ?
I think I will keep the while as they are, and work only on those
which only have the .hasNext().
Thanks for your comments !
> Jacques
>
> From: "Paul Foxworthy"
>
>> Hi Erwan,
>>
>> To be sure there is no Null Pointer Exception, yes, you need to test for
>> null first. One possibility is to just let the NPE happen.
>>
>> The discussion at
>>
>> http://stackoverflow.com/questions/2250031/null-check-in-an-enhanced-for-loop
>>
>> suggests
>>
>> for( Object o : safe( list ) ) {
>> // do whatever
>> }
>>
>> Where safe would be:
>>
>> public static List safe( List other ) {
>> return other == null ? Collections.EMPTY_LIST : other;
>> }
>>
>> Cleaner code. I suspect the method would be inlined by most Java
>> compilers.
>>
>> Cheers
>>
>> Paul Foxworthy
>>
>>
>> Erwan de FERRIERES-3 wrote
>>>
>>>
>>> Hi,
>>>
>>> I'm trying to remove a lot of iterators, and use the for-each syntax,
>>> which exists since java 1.5.
>>> During my journey, I found a lot of double tests for a while like this
>>> one:
>>>
>>> while (typePurposes != null && typePurposes.hasNext()) {
>>> (ContactMechWorker.java line 606)
>>>
>>> Can it be simplified to for(GenericValue contactMechTypePurpose :
>>> theList) ? Or should I keep it like it is ?
>>>
>>> Regards,
>>>
>>> --
>>> Erwan de FERRIERES
>>> www.nereide.biz
>>>
>>
>> -
>> --
>> Coherent Software Australia Pty Ltd
>> http://www.cohsoft.com.au/
>>
>> Bonsai ERP, the all-inclusive ERP system
>> http://www.bonsaierp.com.au/
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/loop-code-simplification-tp4487741p4488324.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
--
Erwan de FERRIERES
Re: Lose Weight Program for OFBiz - guiapp and pos
Makes sense Jacopo On Mar 20, 2012, at 3:58 PM, Jacques Le Roux wrote: > From: "Jacopo Cappellato" >>> A) move framework/guiapp out of the framework; after all these years no >>> code made advantage of it being part of the framework and it is only used >>> by the specialpurpose/pos component (which was the component for which it >>> was built for); so guiapp can go in the pos component >>> >>> B) specialpurpose/pos: move to "Extras" >>> >> >> No one objected so far; Jacques offered his help for #A. >> Should we focus on #A for now (it is an actionable item) and then discuss #B >> also based on the outcome of similar discussions for other specialpurpose >> components? > > Yes, I know there are POS users out there. So I now wonder if we should not > wait before moving it out of specialpurpose. When you think about it, it's > the twin of eCommerce. With a bit more involvment though, mostly because of > its relation with Entity Sync (maintenance) which is actually part of the > framework (entityext component). > > Jacques
Re: Default package size assumed by fedex?
Beware, see Si Chen last message on user ML <> Jacques From: "Prince Sewani" Hi All, I've a question, If the 'shipment.fedex.default.packagingType' is set to 'YOURPACKNG' , then what are the default dimensions assumed by Fedex for the package in which the product will be packed? I see a lot of difference in rates when I log-into Fedex a/c and give the zip codes, the difference in rate still lies whether I provide the dimensions of the package or not. Any pointers/clues will be of great help. Regards Prince
Re: Lose Weight Program for OFBiz - themes
From: "Mansour Al Akeel" Flat Gray is simple, and clear. It serves well as a basic theme. AFAIK, it the only theme that supports both directions for languages LTR and RTL. Right and Tomahawk is the last evolution of all others. I prefer Tomahawk: it's easier to find you way because of hierarchised menus (with only 2 levels). Flat Gray is a must have because of LTR and RTL (thanks Adrian!) One project for all themes in Extra makes sense to me. Some/all? (all but Bizzness are pre-evolutions of Tomahawk) could go in Attic (I never got to use Bizzness), to be voted... Jacques On Tue, Mar 20, 2012 at 10:33 AM, wrote: My preference is to keep Flat Grey and one other theme - I have no preference on what that other theme is. -Adrian Quoting Jacopo Cappellato : I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two) Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. Jacopo
Re: Lose Weight Program for OFBiz - example, exampleext
From: I believe the original purpose of the Example component was to provide a very basic application that new developers can analyze and learn from. Running the ant task creates an empty application - there is nothing to see there. So, here is the use case: I need to train new developers to write an OFBiz application, and I need a basic functional application to point them to. The training could occur with a framework-only instance of OFBiz. This makes sense, but then why in framework and not whole in specialpurporse? If we slim down specialpurpose, this should not make a huge difference. Jacques -Adrian Quoting Jacopo Cappellato : 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
Re: loop code simplification
BTW, this shows how stupid is the for loop in Java implementation. The
suggested safeList() should be handled by the compiler IMO, I
see no gains to not have it in but to get NPEs. Did I miss something?
Jacques
From: "Paul Foxworthy"
Hi Erwan,
To be sure there is no Null Pointer Exception, yes, you need to test for
null first. One possibility is to just let the NPE happen.
The discussion at
http://stackoverflow.com/questions/2250031/null-check-in-an-enhanced-for-loop
suggests
for( Object o : safe( list ) ) {
// do whatever
}
Where safe would be:
public static List safe( List other ) {
return other == null ? Collections.EMPTY_LIST : other;
}
Cleaner code. I suspect the method would be inlined by most Java compilers.
Cheers
Paul Foxworthy
Erwan de FERRIERES-3 wrote
Hi,
I'm trying to remove a lot of iterators, and use the for-each syntax,
which exists since java 1.5.
During my journey, I found a lot of double tests for a while like this
one:
while (typePurposes != null && typePurposes.hasNext()) {
(ContactMechWorker.java line 606)
Can it be simplified to for(GenericValue contactMechTypePurpose :
theList) ? Or should I keep it like it is ?
Regards,
--
Erwan de FERRIERES
www.nereide.biz
-
--
Coherent Software Australia Pty Ltd
http://www.cohsoft.com.au/
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/loop-code-simplification-tp4487741p4488324.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
From: "Jacopo Cappellato" H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to "Extras" (if there are persons interested to become committers/maintainers) or to "Attic" There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the "exampleext" component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the "concept" of specialpurpose application is in general better suited for Apache Extras rather than for the OFBiz svn and releases. Basically I'd keep only eCommerce and POS, maybe asset maintenance (arguments?). LDAP could be moved IMO, else why not crowd, etc. The less exceptions the better Jacques
Re: Lose Weight Program for OFBiz - guiapp and pos
From: "Jacopo Cappellato" A) move framework/guiapp out of the framework; after all these years no code made advantage of it being part of the framework and it is only used by the specialpurpose/pos component (which was the component for which it was built for); so guiapp can go in the pos component B) specialpurpose/pos: move to "Extras" No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components? Yes, I know there are POS users out there. So I now wonder if we should not wait before moving it out of specialpurpose. When you think about it, it's the twin of eCommerce. With a bit more involvment though, mostly because of its relation with Entity Sync (maintenance) which is actually part of the framework (entityext component). Jacques
Re: Lose Weight Program for OFBiz JCR function
From: "Nicolas Malin" Le 20/03/2012 11:48, Jacopo Cappellato a écrit : Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) I agree, refactoring content to separate a little more technical and functional element, it's not easier to implement JCR without a main reflexion on content. We implement an EDM with content and an interface between document repository (file, text, sound) and content service appears needed, independently than JCR (open the plugin document engine solution :) ) Could be part of the proposed join effort... Jacques Nicolas At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework" Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz JCR function
Sounds like a plan Jacques From: "Sascha Rodekamp" Hi, 1) keep it in framework +1 2) but remove it from the upcoming new release branch 12.04 +1 - for now the JCR implementation provide the the developer an API which helps to create, read, update or delete content in the repository. We have no integration in other (i.e. the content) applications. So there is no problem to keep the jcr implementation out of release 12.04. 3) and then, as a community, we could start the effort +1 - that was the intention of the Jira Task OFBIZ-4659. There is a lot work to do. I like the idea having a roadmap, that could possibly speed up the development and let people focus on certain features... Thanks and regards, Sascha 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework" Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo -- Sascha Rodekamp Visit the new german OFBiz Blog: http://www.ofbiz.biz Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de
Re: Lose Weight Program for OFBiz - example, exampleext
Yes, making it an extra is an option. -Adrian Quoting Mansour Al Akeel : is it possible to download the "example" separately for new comers ? On Tue, Mar 20, 2012 at 10:28 AM, wrote: I believe the original purpose of the Example component was to provide a very basic application that new developers can analyze and learn from. Running the ant task creates an empty application - there is nothing to see there. So, here is the use case: I need to train new developers to write an OFBiz application, and I need a basic functional application to point them to. The training could occur with a framework-only instance of OFBiz. -Adrian Quoting Jacopo Cappellato : 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
Re: Lose Weight Program for OFBiz - example, exampleext
is it possible to download the "example" separately for new comers ? On Tue, Mar 20, 2012 at 10:28 AM, wrote: > I believe the original purpose of the Example component was to provide a > very basic application that new developers can analyze and learn from. > Running the ant task creates an empty application - there is nothing to see > there. > > So, here is the use case: I need to train new developers to write an OFBiz > application, and I need a basic functional application to point them to. The > training could occur with a framework-only instance of OFBiz. > > -Adrian > > > Quoting Jacopo Cappellato : > >>> 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 >> >> > > >
Re: Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty
I have always had a problem with OS-specific code being maintained in OFBiz. Granted, we have some artifacts that must take the OS into consideration in order to get OFBiz to work, but it appears to me the Debian stuff doesn't fall into that category (I could be wrong, please correct me if I am). For example, we have start scripts (startofbiz.*) as a convenience for users running on various platforms, but those scripts are somewhat generic. Is the Debian stuff similar to that or not? +1 on shark and workflow +0 on the rest. Quoting Jacopo Cappellato : C) $OFBIZ_HOME/debian: move to "Attic" D) the seleniumxml code in framework/testtools: move to "Attic" E) specialpurpose/workflow: move to "Attic" F) specialpurpose/shark: move to "Attic" J) framework/appserver: move to "Extras" K) framework/jetty: move to "Extras" (or "Attic") The above are components/features that don't seem to be used/maintained by the community: some of them are very old (workflow, shark, appserver, jetty), some of them are experimental (shark, seleniumxml), some of them are very specialized (debian). I have proposed some of them for the Attic and some of them for the Extras but in theory all of them could go to Extras if we find at least one maintainer for each; if not, each of them could go to Attic. Any ideas? volunteers (OFBiz committers or not)? No one objected or commented on them so far (so I suspect that there could be a lazy consensus); for the seleniumxml code there was also a thread some weeks ago in the user list where there seemed to be a general consensus (also from the original contributors of the work) for the removal (apart from Hans who is using it, it doesn't seem to be used much by the community). Jacopo
[jira] [Created] (OFBIZ-4737) widget.screen.ScreenRenderException in HR Find Internal Job Posting for search Result
widget.screen.ScreenRenderException in HR Find Internal Job Posting for search Result - Key: OFBIZ-4737 URL: https://issues.apache.org/jira/browse/OFBIZ-4737 Project: OFBiz Issue Type: Bug Components: humanres Affects Versions: Release 10.04 Environment: RHEL5 Reporter: patrick LE BLAN In Internal Job Posting while looking Find Internal Job Posting Search Options S earch Results Application Id IJP Status Applying Party Id Application Date Approver Party Job Requisition Id Delete 10010 IJP_APPLIED :ERROR MESSAGE: org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen [component://common/widget/CommonScreens.xml#FindScreenDecorator]: java.lang.NullPointerException (null) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - themes
Flat Gray is simple, and clear. It serves well as a basic theme. AFAIK, it the only theme that supports both directions for languages LTR and RTL. On Tue, Mar 20, 2012 at 10:33 AM, wrote: > My preference is to keep Flat Grey and one other theme - I have no > preference on what that other theme is. > > -Adrian > > > Quoting Jacopo Cappellato : > >>> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them >>> to "Extras"; keep just one (or two) >>> >> >> Jacques proposed to keep Tomahawk (default) and Flat Grey. >> Olivier proposed to keep just one (Tomahawk, I guess). >> No other comments so far. >> What should be do with the remaining themes? Attic or Extras? Are there >> volunteers for Extras? I would suggest that, if we move them to Extras we >> create *one* project only (for all the themes) rather than one project for >> theme... but I would love to get your feedback on this. >> >> Jacopo > > > >
Re: Lose Weight Program for OFBiz - Birt and BI
+1 birt to Extra.
On Tue, Mar 20, 2012 at 10:31 AM, 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 :
>
>>>
>>> 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
>
>
>
>
Re: Lose Weight Program for OFBiz - themes
My preference is to keep Flat Grey and one other theme - I have no preference on what that other theme is. -Adrian Quoting Jacopo Cappellato : I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to "Extras"; keep just one (or two) Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. Jacopo
Re: Lose Weight Program for OFBiz - Birt and BI
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 :
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
[jira] [Updated] (OFBIZ-3458) Encountered the following error message when navigating to the HR application main web page
[ https://issues.apache.org/jira/browse/OFBIZ-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] patrick LE BLAN updated OFBIZ-3458: --- Comment: was deleted (was: please tell how error occurs) > Encountered the following error message when navigating to the HR application > main web page > --- > > Key: OFBIZ-3458 > URL: https://issues.apache.org/jira/browse/OFBIZ-3458 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Release Branch 09.04 > Environment: Performing misc. tasks and after about an hour of > navigating back and forth between HR/Project Manager and MyPortal encountered > this error. >Reporter: Ruth Hoffman > > Here's the error on the main HR web page under the "Company" heading: > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://humanres/widget/CommonScreens.xml#OrgTree]: > org.ofbiz.base.util.GeneralRuntimeException: Error creating GenericValue (SQL > Exception while getting value : createdTxStamp [CREATED_TX_STAMP] (18) > (Invalid cursor state - no current row.)) (Error creating GenericValue (SQL > Exception while getting value : createdTxStamp [CREATED_TX_STAMP] (18) > (Invalid cursor state - no current row.))) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-3458) Encountered the following error message when navigating to the HR application main web page
[ https://issues.apache.org/jira/browse/OFBIZ-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233442#comment-13233442 ] patrick LE BLAN commented on OFBIZ-3458: please tell how error occurs > Encountered the following error message when navigating to the HR application > main web page > --- > > Key: OFBIZ-3458 > URL: https://issues.apache.org/jira/browse/OFBIZ-3458 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: Release Branch 09.04 > Environment: Performing misc. tasks and after about an hour of > navigating back and forth between HR/Project Manager and MyPortal encountered > this error. >Reporter: Ruth Hoffman > > Here's the error on the main HR web page under the "Company" heading: > org.ofbiz.widget.screen.ScreenRenderException: Error rendering screen > [component://humanres/widget/CommonScreens.xml#OrgTree]: > org.ofbiz.base.util.GeneralRuntimeException: Error creating GenericValue (SQL > Exception while getting value : createdTxStamp [CREATED_TX_STAMP] (18) > (Invalid cursor state - no current row.)) (Error creating GenericValue (SQL > Exception while getting value : createdTxStamp [CREATED_TX_STAMP] (18) > (Invalid cursor state - no current row.))) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4674) Human Resource Manager Tree
[ https://issues.apache.org/jira/browse/OFBIZ-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233438#comment-13233438 ] patrick LE BLAN commented on OFBIZ-4674: Same plus can't developp tree whatever relation is given to party for departement. Depth just goes to ONE. > Human Resource Manager Tree > --- > > Key: OFBIZ-4674 > URL: https://issues.apache.org/jira/browse/OFBIZ-4674 > Project: OFBiz > Issue Type: Bug > Components: humanres >Affects Versions: SVN trunk > Environment: Latest Trunk >Reporter: Tom Burns > Attachments: HR Tree Before Sample Accounting Data Loaded.jpg, HR > Tree With Sample Accounting Data Loaded.jpg, HumanResAcctData.xml > > > In the latest trunk the tree off the HR Main menu has some questionable > behavior: > 1. The developer and test persons created in the Accounting application > behave like organizations. > They display the organization icon and context menu. > For example: > Go to Human Resources Main > In the tree open the nodes Development Department > Development Team 1 > Right Click on any of the children Developer1-3. > Developers 1-3 are persons but the context menu presents the functions for an > organization (Add Employee Position / Add Internal Organization). > The Testing entities have the same behavior. > See attached AcctHRBefore.jpg > Expected parties that are persons would not have context functions. > Expected Accounting entities to display icons and behavior in the manner of > the Programmer and Demo Employee created by HumanResDemoData.xml. > For example load the attached HumanResAcctData.xml using Webtools > Entity > Import > Absolute Filename or URL to see the expected result as shown in > attache AcctHRAfter.jpg > 2. The context menu Add Internal Organization allows duplicate organization > entities in the tree. > This by itself does not make business sense and it permits the creation of > recursive structures by selecting the name of the parent for the child. > For example: > Go to Human Resources Main In the tree right click on "Development > department" > In the context menu select Add Internal Organization In the drop down list > select "DEV" Click Create After refresh open the "Development department". > It now contains a child "Development department" which has a child > "Development department" etc etc. > It is also possible to create recursion by adding an organizations parent as > a child. > Substitute party_id "Company" for "DEV" in the above exercise. > Expected unique nodes > 3. Selecting Add Employee Position or Add Person from the context menu opens > the corresponding edit forms with calendar lookup fields. > The calendar form does no open when the lookup icon is clicked. > Expected calendar to open on click. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz - example, exampleext
I believe the original purpose of the Example component was to provide a very basic application that new developers can analyze and learn from. Running the ant task creates an empty application - there is nothing to see there. So, here is the use case: I need to train new developers to write an OFBiz application, and I need a basic functional application to point them to. The training could occur with a framework-only instance of OFBiz. -Adrian Quoting Jacopo Cappellato : 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
Re: Lose Weight Program for OFBiz - Birt and BI
Le 20/03/2012 12:47, Jacopo Cappellato a écrit :
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?
Currently, we work on a POC to use content for reporting, the report
mechanism is selected by the template type. We implement our first
reports with openoffice but I don't see blocking to use birt, jasper or
other. With this methods, all report engine can move on Extras and when
you deploy, you select for specific report the content thus the desired
engine.
My vision : by default Apache OFBiz embed Xsl-fo and when you download a
other report engine, it give some example and standard content reporting.
+1 to move birt in extras :)
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
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
---
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz - example, exampleext
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 example and exampleext are they useful for production site ? if Apache OFBiz implement a plugin manager, why don't use ant (or other) to prepare OFBiz according to its use. If you want develop on OFBiz, when you download from svn run : ant run-install-dev (it's a example ;)) and ant use plugin manager to resolve all extras project that compose the official OFBiz developer package. [my life] At this time, I comment all unneeded components as example on production site. It isn't a problem, just I don't find clean :) [/my life] -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
Re: Lose Weight Program for OFBiz - what should go to specialpurpose
Agree with Jacopo, specialpurpose should be on extras. Scrum depend of projectmgr, the OFBiz extra will be have a dependency management to ensure that all needed components will be present. Nicolas Le 20/03/2012 12:47, Jacopo Cappellato a écrit : H) specialpurpose/*: move several (if not all, apart ecommerce) of the components to "Extras" (if there are persons interested to become committers/maintainers) or to "Attic" There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the "exampleext" component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the "concept" of specialpurpose application is in general better suited for Apache Extras rather than for the OFBiz svn and releases. -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
[jira] [Created] (OFBIZ-4736) Add Product Reviews to the detail Screen
Add Product Reviews to the detail Screen Key: OFBIZ-4736 URL: https://issues.apache.org/jira/browse/OFBIZ-4736 Project: OFBiz Issue Type: Improvement Components: specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Markus M. May Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4736-Add_Product_Reviews_to_the_profile_screen.patch Currently there is no way for a customer to view her/his reviews created in the ecommerce application. This functionality is added with the attached patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4736) Add Product Reviews to the detail Screen
[ https://issues.apache.org/jira/browse/OFBIZ-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus M. May updated OFBIZ-4736: - Attachment: OFBIZ-4736-Add_Product_Reviews_to_the_profile_screen.patch > Add Product Reviews to the detail Screen > > > Key: OFBIZ-4736 > URL: https://issues.apache.org/jira/browse/OFBIZ-4736 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/ecommerce >Affects Versions: SVN trunk >Reporter: Markus M. May >Priority: Minor > Fix For: SVN trunk > > Attachments: > OFBIZ-4736-Add_Product_Reviews_to_the_profile_screen.patch > > > Currently there is no way for a customer to view her/his reviews created in > the ecommerce application. This functionality is added with the attached > patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4736) Add Product Reviews to the profile Screen
[ https://issues.apache.org/jira/browse/OFBIZ-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus M. May updated OFBIZ-4736: - Summary: Add Product Reviews to the profile Screen (was: Add Product Reviews to the detail Screen) > Add Product Reviews to the profile Screen > - > > Key: OFBIZ-4736 > URL: https://issues.apache.org/jira/browse/OFBIZ-4736 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/ecommerce >Affects Versions: SVN trunk >Reporter: Markus M. May >Priority: Minor > Fix For: SVN trunk > > Attachments: > OFBIZ-4736-Add_Product_Reviews_to_the_profile_screen.patch > > > Currently there is no way for a customer to view her/his reviews created in > the ecommerce application. This functionality is added with the attached > patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz JCR function
Hi, > 1) keep it in framework +1 > 2) but remove it from the upcoming new release branch 12.04 +1 - for now the JCR implementation provide the the developer an API which helps to create, read, update or delete content in the repository. We have no integration in other (i.e. the content) applications. So there is no problem to keep the jcr implementation out of release 12.04. > 3) and then, as a community, we could start the effort +1 - that was the intention of the Jira Task OFBIZ-4659. There is a lot work to do. I like the idea having a roadmap, that could possibly speed up the development and let people focus on certain features... Thanks and regards, Sascha > 1) keep it in framework > 2) but remove it from the upcoming new release branch 12.04 > 3) and then, as a community, we could start the effort (i.e. top priority for > upcoming contributions/commits) of defining the set of requirements needed by > the applications to replace the existing Content framework, finalizing the > architecture and start working all on the implementation and migration of > existing applications: this would mean that the community will focus on this > refactoring effort for a while (postponing any other new development to focus > the energy) > > At least in this way we could experiment if the concept of a roadmap is a > viable options and we will not keep and distribute a component under > development waiting to see if and when something good will come out of it. > > Jacopo > > On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: > >> >> On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: >> >>> New thread for only JCR funstion >>> >>> Summary of initial discussion: >>> >>> Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework" >>> >>> Hans: > Also moving the JCR function out is not a good idea however when not > improved in the next few months using the content manager, i would agree > to a removal. >>> >>> Jacoppo >> Keep it mind we are preparing for the creation of the new release branch >> (12.04): this would mean that all the future releases for 12.04 will be >> bundled with an incomplete JCR/Jackrabbit integration that duplicates >> (but not replaces) the existing Component framework. This is alone a >> good reason for moving this work back to the development branch and will >> save a lot of future work in backporting features if security issues or >> bugs will be discovered. >>> >>> IMO, jcr will be a good enhancement in ofbiz, but currently we(the company >>> I'm working for) are using content component in a lot of place, product, >>> workeffort, project, party, custRequest, to manage files, so we area >>> waiting the next step of the jcr OFBiz (content) integration. >>> Meanwhile this second step, if jcr was a plugin, we will use it for some >>> new customer project (and maybe contribute on ;-) but not use it for older >>> customer which currently works with OFBiz solution to avoid using not >>> completely implement feature. >>> So IMO, jcr should move, branch or extra, but I prefer as a plugin to be >>> able to used it easily. >>> >> >> I didn't follow the details of the plans for JCR/Jackrabbit integration but >> as far as I understand it it is intended to be highly integrated with OFBiz >> (to replace Content Framework features): I am not sure how this is inline >> with Olivier's idea of a plugin, but it is an idea that can be explored. >> However, since we are still in this design phase I think it is a good idea >> to keep the component in the development branch in the meantime. >> >> Jacopo >> > -- Sascha Rodekamp Visit the new german OFBiz Blog: http://www.ofbiz.biz Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de
Re: loop code simplification
Well If we're talking about the 'Enhanced For loop' in Java from 1.5 onwards
Then it goes something like this, you'll only get NPE if you haven't
initialized the collection,
otherwise if you've initialized the collection and there are no values in it
then
the for loop won't execute any iteration.
For example :
import java.util.ArrayList;
class Test{
static ArrayListt;
public static void main(String [] args){
System.out.println("before===");
for(String k : t){
System.out.println(""+k);
}
System.out.println("after===");
}
}
The above program will generate an NPE when ran and the output will be :
before===
Exception in thread "main" java.lang.NullPointerException
at Test.main(Test.java:11)
but if I replace the ArrayList declaration with :
static ArrayList t = new ArrayList();
then the output will be :
before===
after===
Hope this helps.
Regards
Prince
From: Paul Foxworthy
To: dev@ofbiz.apache.org
Sent: Tuesday, March 20, 2012 4:17 PM
Subject: Re: loop code simplification
Hi Erwan,
To be sure there is no Null Pointer Exception, yes, you need to test for
null first. One possibility is to just let the NPE happen.
The discussion at
http://stackoverflow.com/questions/2250031/null-check-in-an-enhanced-for-loop
suggests
for( Object o : safe( list ) ) {
// do whatever
}
Where safe would be:
public static List safe( List other ) {
return other == null ? Collections.EMPTY_LIST : other;
}
Cleaner code. I suspect the method would be inlined by most Java compilers.
Cheers
Paul Foxworthy
Erwan de FERRIERES-3 wrote
>
> Hi,
>
> I'm trying to remove a lot of iterators, and use the for-each syntax,
> which exists since java 1.5.
> During my journey, I found a lot of double tests for a while like this
> one:
>
> while (typePurposes != null && typePurposes.hasNext()) {
> (ContactMechWorker.java line 606)
>
> Can it be simplified to for(GenericValue contactMechTypePurpose :
> theList) ? Or should I keep it like it is ?
>
> Regards,
>
> --
> Erwan de FERRIERES
> www.nereide.biz
>
-
--
Coherent Software Australia Pty Ltd
http://www.cohsoft.com.au/
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/loop-code-simplification-tp4487741p4488324.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Default package size assumed by fedex?
Hi All, I've a question, If the 'shipment.fedex.default.packagingType' is set to 'YOURPACKNG' , then what are the default dimensions assumed by Fedex for the package in which the product will be packed? I see a lot of difference in rates when I log-into Fedex a/c and give the zip codes, the difference in rate still lies whether I provide the dimensions of the package or not. Any pointers/clues will be of great help. Regards Prince
Lose Weight Program for OFBiz - debian, seleniumxml, workflow, shark, appserver, jetty
> C) $OFBIZ_HOME/debian: move to "Attic" > > D) the seleniumxml code in framework/testtools: move to "Attic" > > E) specialpurpose/workflow: move to "Attic" > > F) specialpurpose/shark: move to "Attic" > > J) framework/appserver: move to "Extras" > > K) framework/jetty: move to "Extras" (or "Attic") The above are components/features that don't seem to be used/maintained by the community: some of them are very old (workflow, shark, appserver, jetty), some of them are experimental (shark, seleniumxml), some of them are very specialized (debian). I have proposed some of them for the Attic and some of them for the Extras but in theory all of them could go to Extras if we find at least one maintainer for each; if not, each of them could go to Attic. Any ideas? volunteers (OFBiz committers or not)? No one objected or commented on them so far (so I suspect that there could be a lazy consensus); for the seleniumxml code there was also a thread some weeks ago in the user list where there seemed to be a general consensus (also from the original contributors of the work) for the removal (apart from Hans who is using it, it doesn't seem to be used much by the community). Jacopo
Lose Weight Program for OFBiz - documents
> O) framework/documents: move the content to Wiki and then move to "Attic" > The broader topic is to move all the artifacts related to online help out of the framework; they should all live under "applications".
Lose Weight Program for OFBiz - themes
> I) $OFBIZ_HOME/themes/*: move a few of them to "Attic" and a few of them to > "Extras"; keep just one (or two) > Jacques proposed to keep Tomahawk (default) and Flat Grey. Olivier proposed to keep just one (Tomahawk, I guess). No other comments so far. What should be do with the remaining themes? Attic or Extras? Are there volunteers for Extras? I would suggest that, if we move them to Extras we create *one* project only (for all the themes) rather than one project for theme... but I would love to get your feedback on this. Jacopo
Lose Weight Program for OFBiz - ofbizwebsite
> G) specialpurpose/ofbizwebsite: move to "Attic" > Jacques and Olivier proposed to move it to Extras instead just in case someone will pick up the work and complete it in the future. I would like to mention that, if the original goal was "to eat our own dog food" and run the OFBiz site on it, then this could be in contrast with the ASF infrastructure offered to the projects. Jacopo
Lose Weight Program for OFBiz - example, exampleext
> 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
Lose Weight Program for OFBiz - datafile
> P) framework/datafile: (who is currently using it?) move to "Extras" or > "Attic"; we could replace it with commons-csv or similar tool > There seems to be a general consensus to keep the component as is. Jacopo
Lose Weight Program for OFBiz - what should go to specialpurpose
> > H) specialpurpose/*: move several (if not all, apart ecommerce) of the > components to "Extras" (if there are persons interested to become > committers/maintainers) or to "Attic" > There seems to be a general agreement to slim down the number of applications in this group and move them to Extras (see exceptions below). I am summarizing here some notes but we should actually use this thread to continue the discussion about what should go to specialpurpose in general rather than focusing on the decision about removal of specific applications; we can then start a separate thread for each component. Adrian would like to keep one or two components to demonstrate the concept of reusing artifacts to create custom applications (Jacopo: can we use the "exampleext" component for this?) Hans would like to keep the ones that he considers feature complete like asset maintenance, LDAP, POS, e-commerce, cmssite, projectmgr and scrum. Jacopo: in my opinion even in the above list provided by Hans there are applications that are barely examples (cmssite) or are very specific implementation of very specific requirements (difficult to be used if your company doesn't have exactly these requirements): projectmgr and scrum; some of these components also extends (adding special purpose fields) the generic data model and this happens even if the user is not interested in evaluating the specialpurpose component. I also don't think that some of the components meet minimum quality requirements to be distributed with OFBiz: for example the scrum component uses a mechanism that is unique to demo its features (i.e. published a demo webapp with online instructions for demo data) that is not used by other applications (and this makes the suite of applications inconsistent); also, the component refers to resources that are owned by Hans' company. All in all, they seem very specific piece of codes that should better live as optional plugins downloaded separately. So in my opinion the "concept" of specialpurpose application is in general better suited for Apache Extras rather than for the OFBiz svn and releases.
Lose Weight Program for OFBiz - guiapp and pos
> A) move framework/guiapp out of the framework; after all these years no code > made advantage of it being part of the framework and it is only used by the > specialpurpose/pos component (which was the component for which it was built > for); so guiapp can go in the pos component > > B) specialpurpose/pos: move to "Extras" > No one objected so far; Jacques offered his help for #A. Should we focus on #A for now (it is an actionable item) and then discuss #B also based on the outcome of similar discussions for other specialpurpose components?
Lose Weight Program for OFBiz - Birt and BI
>
> 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
Re: Lose Weight Program for OFBiz JCR function
Le 20/03/2012 11:48, Jacopo Cappellato a écrit : Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) I agree, refactoring content to separate a little more technical and functional element, it's not easier to implement JCR without a main reflexion on content. We implement an EDM with content and an interface between document repository (file, text, sound) and content service appears needed, independently than JCR (open the plugin document engine solution :) ) Nicolas At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework" Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily. I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ --- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/
[jira] [Issue Comment Edited] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi
[ https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1325#comment-1325 ] Tri Duc Vo edited comment on OFBIZ-4627 at 3/20/12 11:08 AM: - Thank Jacques Remove all and then add all + changes because of SVN Tool (step 04). I feel strange and think so much risks :( It's easier for you if has Local leader and Online tool (ex: Pootle) I'll try again and search for reason was (Author: djjava): Thank Jacques Remove all and then add all + changes because of SVN Tool (step 04). I feel strange and think so much risks :( I'll try again > contribute Ofbiz Vietnamese tranlasting to community from HaNoi > --- > > Key: OFBIZ-4627 > URL: https://issues.apache.org/jira/browse/OFBIZ-4627 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: SVN trunk >Reporter: Tri Duc Vo >Assignee: Jacques Le Roux > Labels: features > Fix For: SVN trunk > > Attachments: CommonUiLabels.xml.patch, EcommerceUiLabels.xml, > EcommerceUiLabels.xml.patch, MarketingUiLabels.xml.patch, > OrderEntityLabels.xml.patch, OrderUiLabels.xml.patch, > ProductEntityLabels.xml.patch, ProductUiLabels.xml, ProductUiLabels.xml.patch > > Original Estimate: 1,344h > Remaining Estimate: 1,344h > >Dear Ofbiz community >I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz > opensource. >Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And > we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them > to community. >We'll attach files soon >Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz JCR function
Or alternatively we could: 1) keep it in framework 2) but remove it from the upcoming new release branch 12.04 3) and then, as a community, we could start the effort (i.e. top priority for upcoming contributions/commits) of defining the set of requirements needed by the applications to replace the existing Content framework, finalizing the architecture and start working all on the implementation and migration of existing applications: this would mean that the community will focus on this refactoring effort for a while (postponing any other new development to focus the energy) At least in this way we could experiment if the concept of a roadmap is a viable options and we will not keep and distribute a component under development waiting to see if and when something good will come out of it. Jacopo On Mar 20, 2012, at 11:32 AM, Jacopo Cappellato wrote: > > On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: > >> New thread for only JCR funstion >> >> Summary of initial discussion: >> >> Jacoppo: >>> N) framework/jcr: move back into the Jackrabbit branch until the work is >>> completed and can replace the existing "content framework" >> >> Hans: Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. >> >> Jacoppo > Keep it mind we are preparing for the creation of the new release branch > (12.04): this would mean that all the future releases for 12.04 will be > bundled with an incomplete JCR/Jackrabbit integration that duplicates > (but not replaces) the existing Component framework. This is alone a good > reason for moving this work back to the development branch and will save > a lot of future work in backporting features if security issues or bugs > will be discovered. >> >> IMO, jcr will be a good enhancement in ofbiz, but currently we(the company >> I'm working for) are using content component in a lot of place, product, >> workeffort, project, party, custRequest, to manage files, so we area >> waiting the next step of the jcr OFBiz (content) integration. >> Meanwhile this second step, if jcr was a plugin, we will use it for some >> new customer project (and maybe contribute on ;-) but not use it for older >> customer which currently works with OFBiz solution to avoid using not >> completely implement feature. >> So IMO, jcr should move, branch or extra, but I prefer as a plugin to be >> able to used it easily. >> > > I didn't follow the details of the plans for JCR/Jackrabbit integration but > as far as I understand it it is intended to be highly integrated with OFBiz > (to replace Content Framework features): I am not sure how this is inline > with Olivier's idea of a plugin, but it is an idea that can be explored. > However, since we are still in this design phase I think it is a good idea to > keep the component in the development branch in the meantime. > > Jacopo >
Re: loop code simplification
Hi Erwan,
To be sure there is no Null Pointer Exception, yes, you need to test for
null first. One possibility is to just let the NPE happen.
The discussion at
http://stackoverflow.com/questions/2250031/null-check-in-an-enhanced-for-loop
suggests
for( Object o : safe( list ) ) {
// do whatever
}
Where safe would be:
public static List safe( List other ) {
return other == null ? Collections.EMPTY_LIST : other;
}
Cleaner code. I suspect the method would be inlined by most Java compilers.
Cheers
Paul Foxworthy
Erwan de FERRIERES-3 wrote
>
> Hi,
>
> I'm trying to remove a lot of iterators, and use the for-each syntax,
> which exists since java 1.5.
> During my journey, I found a lot of double tests for a while like this
> one:
>
> while (typePurposes != null && typePurposes.hasNext()) {
> (ContactMechWorker.java line 606)
>
> Can it be simplified to for(GenericValue contactMechTypePurpose :
> theList) ? Or should I keep it like it is ?
>
> Regards,
>
> --
> Erwan de FERRIERES
> www.nereide.biz
>
-
--
Coherent Software Australia Pty Ltd
http://www.cohsoft.com.au/
Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/loop-code-simplification-tp4487741p4488324.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Lose Weight Program for OFBiz JCR function
On Mar 20, 2012, at 10:15 AM, Olivier Heintz wrote: > New thread for only JCR funstion > > Summary of initial discussion: > > Jacoppo: >> N) framework/jcr: move back into the Jackrabbit branch until the work is >> completed and can replace the existing "content framework" > > Hans: > >> Also moving the JCR function out is not a good idea however when not > >> improved in the next few months using the content manager, i would agree > >> to a removal. > > Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. > > IMO, jcr will be a good enhancement in ofbiz, but currently we(the company > I'm working for) are using content component in a lot of place, product, > workeffort, project, party, custRequest, to manage files, so we area > waiting the next step of the jcr OFBiz (content) integration. > Meanwhile this second step, if jcr was a plugin, we will use it for some new > customer project (and maybe contribute on ;-) but not use it for older > customer which currently works with OFBiz solution to avoid using not > completely implement feature. > So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able > to used it easily. > I didn't follow the details of the plans for JCR/Jackrabbit integration but as far as I understand it it is intended to be highly integrated with OFBiz (to replace Content Framework features): I am not sure how this is inline with Olivier's idea of a plugin, but it is an idea that can be explored. However, since we are still in this design phase I think it is a good idea to keep the component in the development branch in the meantime. Jacopo
[jira] [Assigned] (OFBIZ-4734) User behaviour issue on auto-completer.
[ https://issues.apache.org/jira/browse/OFBIZ-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya reassigned OFBIZ-4734: -- Assignee: Ashish Vijaywargiya > User behaviour issue on auto-completer. > --- > > Key: OFBIZ-4734 > URL: https://issues.apache.org/jira/browse/OFBIZ-4734 > Project: OFBiz > Issue Type: Bug >Reporter: Deepak Dixit >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: Release Branch 11.04, SVN trunk > > Attachments: OFBIZ-4734-Release11.04.patch, OFBIZ-4734-Trunk.patch > > > Currently if user type in auto-completer text box and if matches found then > list display as auto-completer result list but if no matches found then user > didn't know that result will come or not, even no matches found. > Change behaviour is when user type in text box then spinner (ajax loader > image) shows wchich tells user that search is in progress. > If matches found or not found spinner disapperars and reult/ no result > message listed in auto-completer relsult list. > Now user won't see any abnormal behaviour at ui. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OFBIZ-4735) User behaviour issue on Lookup.
[ https://issues.apache.org/jira/browse/OFBIZ-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya reassigned OFBIZ-4735: -- Assignee: Ashish Vijaywargiya > User behaviour issue on Lookup. > --- > > Key: OFBIZ-4735 > URL: https://issues.apache.org/jira/browse/OFBIZ-4735 > Project: OFBiz > Issue Type: Bug > Components: framework >Reporter: Deepak Dixit >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: Release Branch 11.04, SVN trunk > > Attachments: OFBIZ-4735-11.04.patch, OFBIZ-4735.patch > > > Currently if user perform search or use pagination in lookup and if matches > found then list display but if no matches found then user didn't know that > result will come or not, even no matches found. > Change behaviour should be when user perform search or use pagination then > spinner (ajax loader image) shows wchich tells user that search is in > progress. > If matches found or not found spinner disappears. > Now user won't see any abnormal behaviour at ui. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi
[ https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1325#comment-1325 ] Tri Duc Vo commented on OFBIZ-4627: --- Thank Jacques Remove all and then add all + changes because of SVN Tool (step 04). I feel strange and think so much risks :( I'll try again > contribute Ofbiz Vietnamese tranlasting to community from HaNoi > --- > > Key: OFBIZ-4627 > URL: https://issues.apache.org/jira/browse/OFBIZ-4627 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: SVN trunk >Reporter: Tri Duc Vo >Assignee: Jacques Le Roux > Labels: features > Fix For: SVN trunk > > Attachments: CommonUiLabels.xml.patch, EcommerceUiLabels.xml, > EcommerceUiLabels.xml.patch, MarketingUiLabels.xml.patch, > OrderEntityLabels.xml.patch, OrderUiLabels.xml.patch, > ProductEntityLabels.xml.patch, ProductUiLabels.xml, ProductUiLabels.xml.patch > > Original Estimate: 1,344h > Remaining Estimate: 1,344h > >Dear Ofbiz community >I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz > opensource. >Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And > we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them > to community. >We'll attach files soon >Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OFBIZ-4735) User behaviour issue on Lookup.
[ https://issues.apache.org/jira/browse/OFBIZ-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepak Dixit updated OFBIZ-4735: Attachment: OFBIZ-4735.patch OFBIZ-4735-11.04.patch Added ajax-loader image on the find screenlet title bar. Thansk Anil Gupta for tht patch and Rishi Solanki for the discussion. > User behaviour issue on Lookup. > --- > > Key: OFBIZ-4735 > URL: https://issues.apache.org/jira/browse/OFBIZ-4735 > Project: OFBiz > Issue Type: Bug > Components: framework >Reporter: Deepak Dixit >Priority: Minor > Fix For: Release Branch 11.04, SVN trunk > > Attachments: OFBIZ-4735-11.04.patch, OFBIZ-4735.patch > > > Currently if user perform search or use pagination in lookup and if matches > found then list display but if no matches found then user didn't know that > result will come or not, even no matches found. > Change behaviour should be when user perform search or use pagination then > spinner (ajax loader image) shows wchich tells user that search is in > progress. > If matches found or not found spinner disappears. > Now user won't see any abnormal behaviour at ui. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz
On Mar 20, 2012, at 10:28 AM, Hans Bakker wrote: > Use the Moqui approach and separate in > > 1. framework, > 2. services and entities > 3. application components By the way, as I mentioned in another thread, I like very much the idea above of having a lighter framework, a library of generic services and entities and *one* ERP component/application that represents the implementation of a specific ERP system that is still rather generic/configurable (but not too much, we could build it considering a medium company in the retail industry purchasing/manufacturing/selling different types of products like services and goods and most of all we should give up pretending that what we have right now can be used to serve a universal company or be extended to serve virtually any company in the World)... similar to the existing applications but much cleaner; then some add ons (external to the above layers) could add reporting/etc... capabilities or add external specialized applications (e.g. steel industry, scrum, paper industry etc...). Jacopo
[jira] [Created] (OFBIZ-4735) User behaviour issue on Lookup.
User behaviour issue on Lookup. --- Key: OFBIZ-4735 URL: https://issues.apache.org/jira/browse/OFBIZ-4735 Project: OFBiz Issue Type: Bug Components: framework Reporter: Deepak Dixit Priority: Minor Fix For: Release Branch 11.04, SVN trunk Currently if user perform search or use pagination in lookup and if matches found then list display but if no matches found then user didn't know that result will come or not, even no matches found. Change behaviour should be when user perform search or use pagination then spinner (ajax loader image) shows wchich tells user that search is in progress. If matches found or not found spinner disappears. Now user won't see any abnormal behaviour at ui. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi
[ https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233282#comment-13233282 ] Tri Duc Vo edited comment on OFBIZ-4627 at 3/20/12 9:48 AM: Dear mr Jacquest/ Ofbiz Please revise our translation job patch for revision 1302146, because of heavy language keys so now we contribute: 1- \applications\marketing\config\MarketingUiLabels.xml 2- \applications\order\config\OrderEntityLabels.xml 3- \applications\order\config\OrderUiLabels.xml 4- \applications\product\config\ProductEntityLabels.xml 5- \applications\product\config\ProductUiLabels.xml 6- \framework\common\config\CommonUiLabels.xml 7- \ecommerce\config\EcommerceUiLabels.xml We do as : 1- Using tool: https://issues.apache.org/jira/browse/OFBIZ-4627 2- Export to .po files 3- Merge to .xml files (fix for escape sequence) 4- Create patch files by SVN If there is any problem , please tell me Thank you very much was (Author: djjava): Dear mr Jacquest/ Ofbiz Please revise our translation job patch for revision 1302146, because of heavy language keys so now we contribute: 1- \applications\marketing\config\MarketingUiLabels.xml 2- \applications\order\config\OrderEntityLabels.xml 3- \applications\order\config\OrderUiLabels.xml 4- \applications\product\config\ProductEntityLabels.xml 5- \applications\product\config\ProductUiLabels.xml 6- \applications\workeffort\config\WorkEffortEntityLabels.xml 7- \framework\common\config\CommonUiLabels.xml 8- \ecommerce\config\EcommerceUiLabels.xml We do as : 1- Using tool: https://issues.apache.org/jira/browse/OFBIZ-4627 2- Export to .po files 3- Merge to .xml files (fix for escape sequence) 4- Create patch files by SVN If there is any problem , please tell me Thank you very much > contribute Ofbiz Vietnamese tranlasting to community from HaNoi > --- > > Key: OFBIZ-4627 > URL: https://issues.apache.org/jira/browse/OFBIZ-4627 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: SVN trunk >Reporter: Tri Duc Vo >Assignee: Jacques Le Roux > Labels: features > Fix For: SVN trunk > > Attachments: CommonUiLabels.xml.patch, EcommerceUiLabels.xml, > EcommerceUiLabels.xml.patch, MarketingUiLabels.xml.patch, > OrderEntityLabels.xml.patch, OrderUiLabels.xml.patch, > ProductEntityLabels.xml.patch, ProductUiLabels.xml, ProductUiLabels.xml.patch > > Original Estimate: 1,344h > Remaining Estimate: 1,344h > >Dear Ofbiz community >I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz > opensource. >Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And > we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them > to community. >We'll attach files soon >Thank you -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lose Weight Program for OFBiz
I think that the slim down approach we are trying to implement, will help if and when we will decide to migrate to Moqui: Moqui is already a slimmed down framework and if our ootb applications will not rely on a fat framework will be easy to migrate; also having less code to maintain and migrate will make the migration to Moqui a more viable option for the community. Of course the migration to Moqui will represent a revolutionary approach that would be carefully evaluated with the community while this slim down roadmap is an evolution (that can be done in steps) that is not alternative to the switch to Moqui. Jacopo On Mar 20, 2012, at 10:28 AM, Hans Bakker wrote: > Jacopo, > > there is another alternative not listed here: > Use the Moqui approach and separate in > > 1. framework, > 2. services and entities > 3. application components > > and concider a conversion path to the moqui framework. > > Regards > Hans > > > On 03/20/2012 04:15 PM, Jacopo Cappellato wrote: >> Thanks to all of you for the great discussion and feedback: I really >> appreciate all the time and great ideas you have shared. >> >> There seems to be a general agreement (with exceptions) about the following >> points: >> * the size of OFBiz should be reduced >> * some components/features can go to Attic (i.e. removed) if properly >> documented (to give a chance in the future to resurrect them) >> * some components/features can go to Extras >> * the community should explore and enhance the plug-in approach, where we >> help to grow an ecosystem with new contributors of optional/external >> components that can be downloaded separately and deployed to OFBiz; Apache >> Extras seems a good candidate and valid initial approach (Hans disagrees on >> this); in the same time OFBiz structure should evolve in a direction that >> helps the plug-in approach (to be designed/discussed separately) >> >> I am starting separate threads to discuss specific topics/actionable items. >> >> Kind regards, >> >> Jacopo >> >> On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote: >> >>> In the last period the OFBiz project has grown a lot in shape: the >>> implicitly accepted (or tolerated) strategy operated by the active >>> committers was that the more features you could add to the official >>> repository the better was: you make happy the contributors, making them >>> feel like they are a part of something, and each committer could manage the >>> code implemented for his/her own projects directly in the OFBiz codebase. >>> >>> We operated under the concept that, since the code if "free" and the author >>> (committer or not) is willing to contribute it, then no one should/could >>> complain if it is added to the repository, if it doesn't cause immediate >>> problems to others; all in all it is an additional feature that may be used >>> by someone else in the future or if not would simply stay there without >>> causing any harm. >>> Following this strategy we got a lot of code like for example Webslinger, >>> seleniumxml, debian packages, all sort of specialpurpose applications etc... >>> >>> Since there was not a central and agreed upon roadmap, no one could really >>> state that a contribution was not a good fit for the project: each and >>> every committer could add what, in his own personal vision, was good for >>> the project. >>> >>> The wrong assumption is that, since the code if "free" then it doesn't harm >>> to include it. This is completely *wrong*: the code is not *free* at all >>> because as soon as you add it to the repository then you add a future cost >>> to the community: you all know that in the software industry the cost to >>> maintain a piece of code is by far greater than the cost to write it; and >>> you *have* to maintain the code unless you want to have and distribute >>> stale code. >>> And this is exactly what we have now: >>> * high costs to maintain the code (e.g. I recently spent a lot of hours to >>> remove the Webslinger component) >>> * stale/unused/half baked code that causes confusion and bad impression to >>> user evaluating the quality of our product >>> >>> The message to all the committers is: when you add code to the repository, >>> you are asking the community to take care of its maintenance costs forever. >>> So please, add new code only when it is really beneficial to the project >>> and to a large audience of committers and users. >>> >>> It is like feeding a wild animal at the zoo with chips: everyone knows it >>> is bad for its health but when you are there it is so nice when it picks >>> the food from your own hands and you cannot resist and have to feed it. >>> >>> OFBiz is now suffering from serious weight issues: the committers community >>> is having an hard time to maintain the huge codebase, it is difficult to >>> keep track of all the features in the system etc... >>> >>> I think it is important to start a new phase of the project and focus ou
Re: Lose Weight Program for OFBiz
Jacopo, there is another alternative not listed here: Use the Moqui approach and separate in 1. framework, 2. services and entities 3. application components and concider a conversion path to the moqui framework. Regards Hans On 03/20/2012 04:15 PM, Jacopo Cappellato wrote: Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared. There seems to be a general agreement (with exceptions) about the following points: * the size of OFBiz should be reduced * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them) * some components/features can go to Extras * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately) I am starting separate threads to discuss specific topics/actionable items. Kind regards, Jacopo On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote: In the last period the OFBiz project has grown a lot in shape: the implicitly accepted (or tolerated) strategy operated by the active committers was that the more features you could add to the official repository the better was: you make happy the contributors, making them feel like they are a part of something, and each committer could manage the code implemented for his/her own projects directly in the OFBiz codebase. We operated under the concept that, since the code if "free" and the author (committer or not) is willing to contribute it, then no one should/could complain if it is added to the repository, if it doesn't cause immediate problems to others; all in all it is an additional feature that may be used by someone else in the future or if not would simply stay there without causing any harm. Following this strategy we got a lot of code like for example Webslinger, seleniumxml, debian packages, all sort of specialpurpose applications etc... Since there was not a central and agreed upon roadmap, no one could really state that a contribution was not a good fit for the project: each and every committer could add what, in his own personal vision, was good for the project. The wrong assumption is that, since the code if "free" then it doesn't harm to include it. This is completely *wrong*: the code is not *free* at all because as soon as you add it to the repository then you add a future cost to the community: you all know that in the software industry the cost to maintain a piece of code is by far greater than the cost to write it; and you *have* to maintain the code unless you want to have and distribute stale code. And this is exactly what we have now: * high costs to maintain the code (e.g. I recently spent a lot of hours to remove the Webslinger component) * stale/unused/half baked code that causes confusion and bad impression to user evaluating the quality of our product The message to all the committers is: when you add code to the repository, you are asking the community to take care of its maintenance costs forever. So please, add new code only when it is really beneficial to the project and to a large audience of committers and users. It is like feeding a wild animal at the zoo with chips: everyone knows it is bad for its health but when you are there it is so nice when it picks the food from your own hands and you cannot resist and have to feed it. OFBiz is now suffering from serious weight issues: the committers community is having an hard time to maintain the huge codebase, it is difficult to keep track of all the features in the system etc... I think it is important to start a new phase of the project and focus our energy in cleanup and consolidation of what we have. One step in this direction is for OFBiz to lose weight. In order to get the ball rolling and focus on some concrete tasks I am providing here some examples of stuff that I would like to see removed from the project. IMPORTANT: Please consider that the list is not based on what I think the perfect framework should be (so PLEASE do not reply stating what your ideal framework should have), but simply on the following considerations: * can the component be easily removed by the project? is it independent and can live outside as a plugin? * do we need all this custom code? can't we find a simpler, lighter and better way to implement this? * is this feature used by other code in the system? * is the feature functional? or is it largely incomplete? * is this an old component/code? * is this used by a lot of persons? (this is tricky to decide but you can get a feeling of it by reading the mailing lists, consid
Re: Lose Weight Program for OFBiz
Thanks to all of you for the great discussion and feedback: I really appreciate all the time and great ideas you have shared. There seems to be a general agreement (with exceptions) about the following points: * the size of OFBiz should be reduced * some components/features can go to Attic (i.e. removed) if properly documented (to give a chance in the future to resurrect them) * some components/features can go to Extras * the community should explore and enhance the plug-in approach, where we help to grow an ecosystem with new contributors of optional/external components that can be downloaded separately and deployed to OFBiz; Apache Extras seems a good candidate and valid initial approach (Hans disagrees on this); in the same time OFBiz structure should evolve in a direction that helps the plug-in approach (to be designed/discussed separately) I am starting separate threads to discuss specific topics/actionable items. Kind regards, Jacopo On Mar 18, 2012, at 10:10 AM, Jacopo Cappellato wrote: > In the last period the OFBiz project has grown a lot in shape: the implicitly > accepted (or tolerated) strategy operated by the active committers was that > the more features you could add to the official repository the better was: > you make happy the contributors, making them feel like they are a part of > something, and each committer could manage the code implemented for his/her > own projects directly in the OFBiz codebase. > > We operated under the concept that, since the code if "free" and the author > (committer or not) is willing to contribute it, then no one should/could > complain if it is added to the repository, if it doesn't cause immediate > problems to others; all in all it is an additional feature that may be used > by someone else in the future or if not would simply stay there without > causing any harm. > Following this strategy we got a lot of code like for example Webslinger, > seleniumxml, debian packages, all sort of specialpurpose applications etc... > > Since there was not a central and agreed upon roadmap, no one could really > state that a contribution was not a good fit for the project: each and every > committer could add what, in his own personal vision, was good for the > project. > > The wrong assumption is that, since the code if "free" then it doesn't harm > to include it. This is completely *wrong*: the code is not *free* at all > because as soon as you add it to the repository then you add a future cost to > the community: you all know that in the software industry the cost to > maintain a piece of code is by far greater than the cost to write it; and you > *have* to maintain the code unless you want to have and distribute stale code. > And this is exactly what we have now: > * high costs to maintain the code (e.g. I recently spent a lot of hours to > remove the Webslinger component) > * stale/unused/half baked code that causes confusion and bad impression to > user evaluating the quality of our product > > The message to all the committers is: when you add code to the repository, > you are asking the community to take care of its maintenance costs forever. > So please, add new code only when it is really beneficial to the project and > to a large audience of committers and users. > > It is like feeding a wild animal at the zoo with chips: everyone knows it is > bad for its health but when you are there it is so nice when it picks the > food from your own hands and you cannot resist and have to feed it. > > OFBiz is now suffering from serious weight issues: the committers community > is having an hard time to maintain the huge codebase, it is difficult to keep > track of all the features in the system etc... > > I think it is important to start a new phase of the project and focus our > energy in cleanup and consolidation of what we have. One step in this > direction is for OFBiz to lose weight. > > In order to get the ball rolling and focus on some concrete tasks I am > providing here some examples of stuff that I would like to see removed from > the project. > > IMPORTANT: Please consider that the list is not based on what I think the > perfect framework should be (so PLEASE do not reply stating what your ideal > framework should have), but simply on the following considerations: > * can the component be easily removed by the project? is it independent and > can live outside as a plugin? > * do we need all this custom code? can't we find a simpler, lighter and > better way to implement this? > * is this feature used by other code in the system? > * is the feature functional? or is it largely incomplete? > * is this an old component/code? > * is this used by a lot of persons? (this is tricky to decide but you can get > a feeling of it by reading the mailing lists, considering commit activity, > the status of the feature etc...) > > DISCLAIMER: I know it will be a painful decision because each of us reading > this w
Lose Weight Program for OFBiz JCR function
New thread for only JCR funstion Summary of initial discussion: Jacoppo: N) framework/jcr: move back into the Jackrabbit branch until the work is completed and can replace the existing "content framework" Hans: >> Also moving the JCR function out is not a good idea however when not improved in the next few months using the content manager, i would agree to a removal. Jacoppo Keep it mind we are preparing for the creation of the new release branch (12.04): this would mean that all the future releases for 12.04 will be bundled with an incomplete JCR/Jackrabbit integration that duplicates (but not replaces) the existing Component framework. This is alone a good reason for moving this work back to the development branch and will save a lot of future work in backporting features if security issues or bugs will be discovered. IMO, jcr will be a good enhancement in ofbiz, but currently we(the company I'm working for) are using content component in a lot of place, product, workeffort, project, party, custRequest, to manage files, so we area waiting the next step of the jcr OFBiz (content) integration. Meanwhile this second step, if jcr was a plugin, we will use it for some new customer project (and maybe contribute on ;-) but not use it for older customer which currently works with OFBiz solution to avoid using not completely implement feature. So IMO, jcr should move, branch or extra, but I prefer as a plugin to be able to used it easily.
Re: Lose Weight Program for OFBiz
Hi Hans, Of course you do not have to agree. But, like you implied earlier: let's put it to the vote and see what the outcome will. I assume that you will adhere/comply to the result as well. Regards, Pierre Op 19 maart 2012 13:15 schreef Hans Bakker het volgende: > Jacopo, > > I appreciate you reply and effort, can however not agree with you. Perhaps > for you good reasoning, not for me. > > Regards, > Hans > > > > On 03/19/2012 05:08 PM, Jacopo Cappellato wrote: > >> Hi Hans, >> >> please see inline: >> >> On Mar 19, 2012, at 9:05 AM, Hans Bakker wrote: >> >> Hi Jacopo, >>> >>> Thank you for the effort you spend with OFBiz the last few months. I >>> generally agree that sure we have to cut the dead wood in the system. >>> Components and functions which are not used or only halfway implemented >>> sure, sounds like a good idea to move them out. >>> >>> However the reasons you list as 'high maintenance' i do not agree with. >>> Only with file changes there is work, otherwise it is pretty limited. >>> Removing half baked code sure, lets remove it. >>> >>> The 'not complete' reasons do not apply to several applications and >>> functions you want to remove because they are complete, like asset >>> maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component >>> perhaps better to integrate it with ecommerce), projectmgr and scrum. >>> >> The "not complete" is not the only motivation: I have also considered if >> they seem to be "used" and maintained; or if they follow best practices or >> if they are very specific: some of them are actually a very specific way to >> implement a very specific set of requirements and may be better represented >> as independent optional components that can be downloaded and used only by >> users with these specific needs. >> Keeping all them in will also mean that, if and when the community will >> decide to migrate a technology (e.g. from Freemarker to XYZ or from Screens >> to ABC or from the OFBiz Framework to Moqui) they will also need to be >> maintained and migrated by the community... when the user based may be very >> limited. >> >> Also moving the JCR function out is not a good idea however when not >>> improved in the next few months using the content manager, i would agree to >>> a removal. >>> >> Keep it mind we are preparing for the creation of the new release branch >> (12.04): this would mean that all the future releases for 12.04 will be >> bundled with an incomplete JCR/Jackrabbit integration that duplicates (but >> not replaces) the existing Component framework. This is alone a good reason >> for moving this work back to the development branch and will save a lot of >> future work in backporting features if security issues or bugs will be >> discovered. >> >> Then I was even more surprised, because reporting is a pretty weak point >>> in OFBiz, to remove the Birt integration and data warehouse entities. >>> >> I agree that reporting is a weak point in OFBiz; I disagree that the >> integrated Birt component is the answer to this problem: the integration is >> minimal and the reports that are implemented with Birt are very good >> example of how weak the current integration is: they have a bunch of data >> preparation code buried in them and their layout is very simple too. And >> you still have to define controller entries for the reports and also >> screen/forms for the parameters to invoke them... this is really a small >> help provided by the framework; a real integration, ready to be released >> with OFBiz, should do much more than this (like letting the user to define >> a new report using the report designer only and then "publish it to OFBiz" >> from there without requiring all these programming tasks). And as a side >> effect for having this integration we have to bundle and deliver to all the >> users a big amount of jars; instead this should be an optional (downloaded >> separately) component that only interested users should get (and these >> users will probably already have their own Birt setup). OFbiz should stay >> lighter and should delegate the decision about what reporting engine to use >> to the user. I suspect that, if the user community is really using this >> integration to build reports, we would get a lot of them contributed... and >> this is not happening. >> >> I cannot agree with the removal of these components, Birt integration >>> and JCR (in the short term) >>> >>> Fair enough; we will see what others have to say on this subject as >> well. Then we will take the best decision for the community. >> >> Some other proposals: >>> 1. I would like to push for more junit tests and use even this as a >>> measure to keep a component in the system or not. (cobertura minimum >>> percentage?) >>> >> This is a good idea indeed if the presence/lack of junit test will be >> used as an additional element for the decision; but it can't be the only >> one because we could have a component that has a lot of junit tests but for >
Re: Lose Weight Program for OFBiz
It seems weird to keep a 'demo application' in the framework, purely to facilitate developers. It adds no value to using ofbiz in production. So it should be removable from the framework and and self-contained (no dependencies from other applications). Op 18 maart 2012 12:16 schreef het volgende: > I think Example should stay in the framework, but get rid of all of the > "showroom" stuff that has been added to it. In other words, keep it and > return it to its original purpose - a very basic component for new users to > understand OFBiz. > > I use datafile to connect legacy systems to OFBiz. > > I agree that specialpurpose should be slimmed down, but we should retain > one or two components to demonstrate the concept of reusing artifacts to > create custom applications. > > -Adrian > > > Quoting Jacopo Cappellato > > >: > > In the last period the OFBiz project has grown a lot in shape: the >> implicitly accepted (or tolerated) strategy operated by the active >> committers was that the more features you could add to the official >> repository the better was: you make happy the contributors, making them >> feel like they are a part of something, and each committer could manage the >> code implemented for his/her own projects directly in the OFBiz codebase. >> >> We operated under the concept that, since the code if "free" and the >> author (committer or not) is willing to contribute it, then no one >> should/could complain if it is added to the repository, if it doesn't cause >> immediate problems to others; all in all it is an additional feature that >> may be used by someone else in the future or if not would simply stay there >> without causing any harm. >> Following this strategy we got a lot of code like for example Webslinger, >> seleniumxml, debian packages, all sort of specialpurpose applications etc... >> >> Since there was not a central and agreed upon roadmap, no one could >> really state that a contribution was not a good fit for the project: each >> and every committer could add what, in his own personal vision, was good >> for the project. >> >> The wrong assumption is that, since the code if "free" then it doesn't >> harm to include it. This is completely *wrong*: the code is not *free* at >> all because as soon as you add it to the repository then you add a future >> cost to the community: you all know that in the software industry the cost >> to maintain a piece of code is by far greater than the cost to write it; >> and you *have* to maintain the code unless you want to have and distribute >> stale code. >> And this is exactly what we have now: >> * high costs to maintain the code (e.g. I recently spent a lot of hours >> to remove the Webslinger component) >> * stale/unused/half baked code that causes confusion and bad impression >> to user evaluating the quality of our product >> >> The message to all the committers is: when you add code to the >> repository, you are asking the community to take care of its maintenance >> costs forever. So please, add new code only when it is really beneficial to >> the project and to a large audience of committers and users. >> >> It is like feeding a wild animal at the zoo with chips: everyone knows it >> is bad for its health but when you are there it is so nice when it picks >> the food from your own hands and you cannot resist and have to feed it. >> >> OFBiz is now suffering from serious weight issues: the committers >> community is having an hard time to maintain the huge codebase, it is >> difficult to keep track of all the features in the system etc... >> >> I think it is important to start a new phase of the project and focus our >> energy in cleanup and consolidation of what we have. One step in this >> direction is for OFBiz to lose weight. >> >> In order to get the ball rolling and focus on some concrete tasks I am >> providing here some examples of stuff that I would like to see removed from >> the project. >> >> IMPORTANT: Please consider that the list is not based on what I think the >> perfect framework should be (so PLEASE do not reply stating what your ideal >> framework should have), but simply on the following considerations: >> * can the component be easily removed by the project? is it independent >> and can live outside as a plugin? >> * do we need all this custom code? can't we find a simpler, lighter and >> better way to implement this? >> * is this feature used by other code in the system? >> * is the feature functional? or is it largely incomplete? >> * is this an old component/code? >> * is this used by a lot of persons? (this is tricky to decide but you can >> get a feeling of it by reading the mailing lists, considering commit >> activity, the status of the feature etc...) >> >> DISCLAIMER: I know it will be a painful decision because each of us >> reading this will have a connection with some of the code listed below: >> several hours spent on it, great ideas that never came to a finished plan; >> in fact I feel the sa
Re: Lose Weight Program for OFBiz
Le 19/03/2012 13:12, Hans Bakker a écrit : Scott, I appreciate your reply , but this apache extra's stuff is not working.: the Apache extra's is now over one year old, in that time there are 125 extra's for 84 projects. I even counted all the test and apple dirs.most projects are empty and do not have any extra's sorry i see moving out of special purpose components to extra's as a big error. Your advantages below will not work because Apache extra will be not a success. What is apache extra? A link screen to google projects which have some link to a apache project. Good for single developers, not good for us (Antwebsystems) because we rather use our own infrastructure which is integrated with the OFBiz system scrum component what is not possible with an external svn. If we (the ofbiz community) gives the correct tools (plugin management, Continuous Integration, release publishing, ...) to works with OFBiz Extra and Apache-OFBiz, 1) company could work with their own infrastructure which could be integrated with Apache-OFBiz and OFBiz-Extra 2) it will be possible to have OOTB solution for specifics need 3) users can easily view what is working and so use choose and use it ERP is really a good use case for Kernel and added features, and so it should work with Apache-OFBiz andd OFBiz-Extra Extra publicity? not really , we can publisize links in the ofbiz wiki to our own repository just the same. Regards, Hans On 03/19/2012 05:32 PM, Scott Gray wrote: Hi Hans, I don't want to argue the merits of removing specific portions of code/features/components but I think it's worth mentioning some of the benefits of moving features to Extras: - Greater access to contributors, if someone is making regular quality contributions to a specific Extra then they can easily be granted commit access. Easier for the contributor and no worry for the PMC that we have to grant access to the entire codebase (which in turn is better for the entire community) - Moving something to Extras shouldn't be considered as a loss to OFBiz or to the community. It is merely a means of streamlining and consolidating what is offered by OFBiz OOTB. Personally I envision OFBiz Extras as potentially becoming a vibrant community in itself, if we seed that community with a decent set of add-on functionality then it's quite possible other people would start to do the same. Providing and managing an Extra for the community would bring a type of recognition that donating it directly to OFBiz never could. For a company such as yours that likes to promote itself quite a bit it could actually work out to be an advantage for you. - The benefits of a slimmer OFBiz really can't be understated, at the moment we have something like 7000+ services, I don't know about you but I'd be lucky to be able to describe what maybe 10-20% actually do. The idea that you can download OFBiz, pop over to Extras and gran the things you actually need sounds super appealing to me. Sure it's an extra step that needs to be taken but I don't think that outweighs that benefits of being able to run only what you need. - New features for old releases. With components existing outside of OFBiz, contributors could make newer versions of components compatible with older releases of OFBiz, essentially allowing what we don't currently. If we can build a good community around Extras then I think we could see some amazing things happen in this regard. People could be empowered to do things that would never be accepted into OFBiz but would still be useful to a large number of people. Perhaps someone wants to develop Catalog Manager 2.0 using Apache Wicket or Apache Click or some other UI framework, they could do that and know that it will have an audience because we'll be actively endorsing the Extras community as a place to go for additional functionality. Anyway, I'm not arguing any of your points, I just want to make it clear to you and everyone else that I see this as an opportunity to make more features available for OFBiz rather than any attempt to take out the trash (that's the Attic's job). Regards Scott On 19/03/2012, at 9:05 PM, Hans Bakker wrote: Hi Jacopo, Thank you for the effort you spend with OFBiz the last few months. I generally agree that sure we have to cut the dead wood in the system. Components and functions which are not used or only halfway implemented sure, sounds like a good idea to move them out. However the reasons you list as 'high maintenance' i do not agree with. Only with file changes there is work, otherwise it is pretty limited. Removing half baked code sure, lets remove it. The 'not complete' reasons do not apply to several applications and functions you want to remove because they are complete, like asset maintenance, LDAP, POS, e-commerce, cmssite(demo for the content component perhaps better to integrate it with ecommerce), projectmgr and scrum. Also mo
