my understanding of ofbiz basic design is that the entity define the UI display, which this statement does not follow. so till the Javascript is generated on the fly in the Webapp I consider all efforts to integrate JS, extra effort for the reason stated here.
========================= BJ Freeman Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52> Specialtymarket.com <http://www.specialtymarket.com/> Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Nicolas Malin sent the following on 5/17/2011 2:05 AM: > My comments inline... > > [...] >>>>>> QuantityBreak >>>>>> --------------------- >>>>>> >>>>>> No, don’t get rid of the QuantityBreak entity, and it should be >>>>>> used as >>>>>> part >>>>>> of pricing. Many organisations will have standard QuantityBreaks that >>>>>> apply >>>>>> to a wide range of products. An organization might want to offer >>>>>> various >>>>>> agreed prices to customers, but use the same quantity breaks >>>>>> consistently. >>>>>> It should be possible to add a new price for a product without having >>>>>> to >>>>>> define quantity breaks, with the risk that the newly entered quantity >>>>>> breaks >>>>>> are inconsistent with standard organisation policy. >>>>> Maybe this wasn't clear... the goal is to get rid of the QuantityBreak >>>>> entity and use the quantity fields directly. This significantly >>>>> simplifies >>>>> both the data model and the code. In theory what you say is correct, >>>>> that >>>>> quantity breaks could be maintained separately, but that hasn't >>>>> happened >>>>> in >>>>> any of the OFBiz UIs, and in fact I've never seen anything like that >>>>> actually used (I've seen them built, but then abandoned because for >>>>> the >>>>> user >>>>> they are cumbersome). >>>>> >>>>> If an organization wants a policy of specific quantity breaks they can >>>>> certainly implement that and design the user interface for it, even >>>>> with >>>>> the >>>>> data model designed this way. >>>>> >>>> QuantityBreak is also used for shipping, and quantity breaks for >>>> shipping >>>> are often in terms of weight. I think that's sensible, and the entity >>>> should >>>> not be removed altogether. >>> I'm not quite suire I get clearly which were the 2 quantity fields you >>> spoke about David, I guess it's for pricing and shipping? >>> Then, I tend to agree with Paul here about keeping the QuantityBreak >>> Entity even if we could refactor the code to use the 2 fields >>> (did not look into code and I don't remember OTTOMH). They could >>> still be >>> useful in some specific cases. >>> >>>> For product pricing as opposed to shipping, how about keeping >>>> QuantityBreak, >>>> but only to support UIs? Remove the relationship between QuantityBreak >>>> and >>>> product pricing. What does everyone think? >>> Yes that sounds good to me. The best way would be to provide a patch >>> in a >>> Jira. If it's not used OOTB (Paul's assertion, to be >>> confirmed) then I think we don't need to provide a way for data >>> migration >>> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration >>> > I prefere keep QuantityBreak entity to given the possibility to define > prototype input for user screen. > With QuantityBreakType it's easier to define many formated table price > depending on product type. > > Nicolas >
