Re: [DISCUSSION] Adopting Docker for OFBiz - what are the objectives?
These days we are mostly working in Kubernetes. Docker only takes you part way to the horizontal scalability promised land. On Tue, Dec 1, 2020 at 12:27 PM Eugen Stan wrote: > Hi, > > There has been some discussion regarding Docker and OFBiz, however no > consensus yet. > I'm starting this thread after discussions on Slack with Jacques Le > Roux, Daniel Watford and Michael Brohl. > > The the aim to establish some goals / objectives regarding Docker and > OFBiz. > > Please add your feedback, comments and suggestions. > > Prior work regarding this is found > > https://issues.apache.org/jira/browse/OFBIZ-10407 > > https://lists.apache.org/thread.html/r40fd679818a37e113b469add51755b1097a2b02d3961e71a2cfe928d%40%3Cdev.ofbiz.apache.org%3E > > and in the links stemming from the links above. > > > > == How can we integrate Docker in OFBiz ? > > Docker can be used in two distinct ways: > > a. Use Docker as a way to build OFBiz components - this will make builds > more portable - as long as people have Docker (or containerd or podman) > installed locally, they will be able to build OFBiz "for sure" (tm). > > This aims to solve the issue of people not having the proper JDK and > required tools installed (gradle, git ?! etc). > > b. Use Docker to deploy OFBiz for production purposes (and demos) > IMO this means building a slim Docker image with only JRE and OFBiz + a > custom selection of plugins. IMO this is best achieved with pre-built, > published binaries for ofbiz. > > c. Use Docker to develop / debug OFBiz > I'm not sure if this is really a thing since IMO falls into b). > > > Using docker multi stage image builds is something that could help. > > The goals are sometimes at odds with one another in the sense that doing > something to fix a goal will hinder the other. > > Do you see other use-cases for Docker and OFBiz? > > > == My personal take > > Personally I would like to focus on b). I did not have good experience > with building sources with Docker - I could not get used to the workflow. > > Also when I deploy to production, I don't really care how it's built as > long as I have the binary and I can run just that. > > So we might end up with two or more Dockerfiles, each focusing on > specific objectives. > > > > Regards, > -- > Eugen Stan > +40720 898 747 / netdava.com > -- Ean Schuessler, Brainfood Co-Founder e...@brainfood.com 214-720-0700
Re: [COMMUNITY VOTE RESULT] New OFBiz Logo
This is one of the benefits of the Condorcet style voting that Debian uses. Both option 1 and option 2 would probably have defeated option 3 in an straight contest between the two contestants. A jaded person might speculate that the vote seems constructed to favor the third logo but I have a feeling that this was not a thoughtfully constructed outcome. https://en.wikipedia.org/wiki/Condorcet_method On Wed, Jul 27, 2016 at 7:31 AM, Paul Piper <p...@ilscipio.com> wrote: > Hi Sharan, > > and thanks for the great work on the logo. But didn't the majority vote for > a variation of the current logo? Option 1&2 differ only by the way the > feather is portrayed and there is an even split between both. > > Cheers, > Paul > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble. > com/COMMUNITY-VOTE-RESULT-New-OFBiz-Logo-tp4690080p4690084.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > -- Ean Schuessler, Brainfood Co-Founder e...@brainfood.com 214-720-0700
[jira] [Commented] (OFBIZ-4274) Implement a REST Servlet
[ https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15386584#comment-15386584 ] Ean Schuessler commented on OFBIZ-4274: --- We implemented a solution for an in house project called DirectControlServlet. Honestly it is pretty ugly but it did allow us to more comfortably map Backbonejs models to sets of services. We have a separate config file the maps the combination of a URL and an HTTP method to a given service. You can find it at http://gitlab.brainfood.com/brainfood/ofbiz-directcontrolservlet. > Implement a REST Servlet > > > Key: OFBIZ-4274 > URL: https://issues.apache.org/jira/browse/OFBIZ-4274 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: Trunk >Reporter: Adrian Crum >Priority: Minor > Labels: REST > Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml, > rest-conf.xml > > > Implement a REST servlet that will map REST requests to OFBiz services. > Details are in the comments. > [here is the discussion which took place on the dev > ML|http://markmail.org/message/ai6q2fbksowaayn4] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Building a Winning UX Strategy Using the Kano Model
There are some great ideas in this talk. I don't agree with the notion that adding features is always a negative but an interface becoming too complicated from feature bloat is a reality. One idea we talked about some time ago was a notion of UICAs (User Interface Condition Actions) that would allow for the insertion of UI elements by components. This would allow a component to insert new buttons and menu entries at engineered insertion points at various points in the applications. These would allow a component like the Facility Manager to insert its tabs in the catalog and so on but if facilities weren't needed then those extra tabs would disappear. The whole system could be trimmed back to a base platform with these insertion points throughout it. On Fri, Nov 20, 2015 at 3:32 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Interesting indeed > > Jacques > > > Le 20/11/2015 09:47, Julien NICOLAS a écrit : > >> Hello Ron, >> >> It's really interesting, thanks! >> >> Julien. >> >> Le 20/11/2015 07:41, Ron Wheeler a écrit : >> >>> This video is about the strategy surrounding the user experience. >>> https://www.youtube.com/watch?v=Hr1rN3jibIk >>> >>> There are a lot of ideas about how to use the Kano Model to determine >>> what features should be included in a product. >>> - There are features that are so basic that they do not show up in user >>> requirements - Accounts must balance; Orders should not be lost. >>> These are typically expensive to include and if they work, you get no >>> user satisfaction but if they don't, you create a lot of user >>> dissatisfaction. >>> >>> - There are features that users consider key to the performance of the >>> application and show up as "Features" in marketing docs and RFPs - good >>> documentation, search, multi-tenancy, support for eCommerce gateways, etc. >>> These have a linear line from "few features, unsatisfactory user >>> experience" to "many features with great user experience" >>> >>> - There are features that generate "the WOW reaction". They are not >>> expected to be there but users/buyers are impressed when they are. >>> If they are not included, this does not generate dissatisfaction but >>> if they are there they generate user enthusiasm. >>> >>> The trick is to know where each enhancement requested or suggested fits >>> in the space. >>> >>> As time goes on, the "WOW" features move into the performance class and >>> eventually to the expected class. >>> For example, I can remember when touch screens were really exciting but >>> now a tablet or phone that only supports a keypad could hardly be sold. >>> >>> One of the more interesting parts of the discussion is about why you >>> need a process for saying "No." to new features. >>> How do you keep a piece of software at exactly the right level of >>> complexity? >>> >>> Enjoy. >>> >>> Ron >>> >>> >> >> -- Ean Schuessler, Brainfood Co-Founder e...@brainfood.com 214-720-0700
Re: OFBiz going mobile
The real difficulty is that if you want a genuinely mobile app and not just mobile web then the approach has to completely switch. With a Cordova app you no longer render pages on the server and send them to the client. To behave like an actual app you need to approach it as a program written in Javascript that renders HTML interfaces locally and communicates with the server using a combination of JSON-RPC and REST. This would represent an enormous refactoring of the entire interface but it would open whole new horizons from a UI perspective. David has made some real improvements to handle REST in Moqui's version of the control servlet that we would also need to bring in (ie. you can bind services to a combination of URL and HTTP method). On Wed, Jul 8, 2015 at 11:13 AM, Pierre Smits pierre.sm...@gmail.com wrote: Hi all, There are a lot of mobile specific development frameworks out there. There are even a few projects under the ASF umbrella that cater to that need. What would you consider the best solution to pair OFBiz with? Of are the capabilities it delivers sufficient? Please share your thoughts. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Ean Schuessler, Brainfood Co-Founder e...@brainfood.com 214-720-0700
Re: OFBiz going mobile
The trouble with AngularJS is that they have a terrible case of NIH and are re-inventing all the existing popular patterns like IOC, dependency management and observer style data change events. In the 1.0 version they were dismissive of problems like dependency management and let rediscover the pains of not being able to fractionally load their infrastructure even though it has been a solved problem for tools like RequireJS for a long time. Now the roadmap for AngularJS 2.0 is so different from 1.0 that it might as well be regarded as a different product and there is also real cloudiness around the relationship between AngularJS and Polymer. Google is developing both so the it's made by Google argument that usually puts wind in Angular's sails isn't applicable. On Tue, Jul 28, 2015 at 10:11 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Good analysis. I wonder if Ionic is a good choice for a portable mobile framework. http://ionicframework.com/ One does not want to get tied up in low level support for all the flavors of mobile devices. It is open source and supports AngularJS which seems to be a good model for building Javascript applications, Ron On 28/07/2015 10:25 AM, Ean Schuessler wrote: The real difficulty is that if you want a genuinely mobile app and not just mobile web then the approach has to completely switch. With a Cordova app you no longer render pages on the server and send them to the client. To behave like an actual app you need to approach it as a program written in Javascript that renders HTML interfaces locally and communicates with the server using a combination of JSON-RPC and REST. This would represent an enormous refactoring of the entire interface but it would open whole new horizons from a UI perspective. David has made some real improvements to handle REST in Moqui's version of the control servlet that we would also need to bring in (ie. you can bind services to a combination of URL and HTTP method). On Wed, Jul 8, 2015 at 11:13 AM, Pierre Smits pierre.sm...@gmail.com wrote: Hi all, There are a lot of mobile specific development frameworks out there. There are even a few projects under the ASF umbrella that cater to that need. What would you consider the best solution to pair OFBiz with? Of are the capabilities it delivers sufficient? Please share your thoughts. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 -- Ean Schuessler, Brainfood Co-Founder e...@brainfood.com 214-720-0700
[jira] [Commented] (OFBIZ-6511) Geos have a lifespan
[ https://issues.apache.org/jira/browse/OFBIZ-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14591181#comment-14591181 ] Ean Schuessler commented on OFBIZ-6511: --- I bet there is a mind blowing amount of code that makes assumptions about there being no thru dates on geos. Geos have a lifespan Key: OFBIZ-6511 URL: https://issues.apache.org/jira/browse/OFBIZ-6511 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: Trunk Reporter: Pierre Smits Assignee: Pierre Smits Geo entity records don't have the fromDate and thruDate fields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Widget or not Widget? [Was Re: Addons for OFBiz]
From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Widget or not Widget? [Was Re: Addons for OFBiz] Actually maybe I'm misunderstanding you and I also want to clarify with everybody. I will try to be brief and right to the point! Do you (we) want to replace the widgets by something like Ean and Anil proposed many times, or do we want to improve them using these new tools? I did not propose that we replace the widgets. I proposed that we re-implement the widget rendering in Javascript on the client. There is a big difference.
[jira] [Commented] (OFBIZ-6270) base/json/JSON has been removed, with no deprecation window
[ https://issues.apache.org/jira/browse/OFBIZ-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509726#comment-14509726 ] Ean Schuessler commented on OFBIZ-6270: --- Is the deprecation policy documented? Is it a MUST deprecate by next release? Is there a policy against accepting patches which add missing deprecation? base/json/JSON has been removed, with no deprecation window --- Key: OFBIZ-6270 URL: https://issues.apache.org/jira/browse/OFBIZ-6270 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk, 12.04.04 Reporter: Adam Heath Assignee: Adam Heath Priority: Critical The antlr-based json parser(at org.ofbiz.base.json.JSON.cc) was removed last October(2014-10-27). However, no backwards-compatible class was left in place, with a proper @Deprecation tag applied. The proper approach should have been to leave the class in place, adding @Deprecation, and leaving the json-lib.jar in place. Then, after one successful release, removing the actual code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: move to git.
That raises another irritating thing about the JIRA SVN workflow vs GIT pull requests. If you look at the contributor graph on GitHub for OFBiz you will see that it currently has only 3 contributors. Foremost this is because the project committers have mostly not configured their Apache addresses into their GitHub accounts. Secondly, however, it is caused by the fact that all JIRA committed patches will show the name of the person who merged the patch rather than its original author. https://github.com/apache/ofbiz/graphs/contributors We can make up stories about why this is desirable but I think any honest assessment would conclude that it is an inconvenience at best and a hazard at worst. Eventually if these dots are not connected the origins of some OFBiz code could become as mysterious as the early CVS commits. With the GIT pull request workflow we would not only know who wrote the code but would still know who performed the merge. We could also sign the commits so that their origin is cryptographically confirmed. - Original Message - From: Gil Portenseigne gil.portensei...@nereide.fr Subject: Re: move to git. Yes, but these are commiters contributions, i mean non-commiters one should go thru jira.
Re: move to git.
From: Pierre Smits pierre.sm...@gmail.com Subject: Re: move to git. That, Ean, says more about github than SVN. See https://fisheye6.atlassian.com/users/ofbiz and https://fisheye6.atlassian.com/graph/ofbiz showing a totally different story. How do I see the people who submitted patches via JIRA?
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
From: David E. Jones d...@me.com Subject: Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml This is an appeal to popularity, not utility. I don't think we've proven that those fail to converge over time.
Re: move to git.
From: Pierre Smits pierre.sm...@gmail.com Subject: Re: move to git. By committers referencing the contributors to the JIRA issue in the commit report. But that is not reflected in your referenced visualization: https://fisheye6.atlassian.com/users/ofbiz I think it would be easier if you simply concede that the current process does not let svn blame report the actual authors for patch lines. Here is a simple enough question, which non-committer has submitted the most code to OFBiz and what was the distribution of their changes amongst the various OFBiz components?
Re: move to git.
Comments inline. From: David E. Jones d...@me.com Subject: Re: move to git. It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue. In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit. Precisely so. With GIT the chaos stays at its source until other players decide it is worth pulling into their copies of the world. With SVN you get the chaos of every committer whether you want it or not. (Note: this includes Brainfood's chaos for anyone who wants to mischaracterize my comments as an attack) On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy). At Apachecon, Apache's engineering and corporate leadership advised me that we could move to using OFBiz to manage our issues instead of JIRA if we so desire.
Re: move to git.
Comments inline.
From: Pierre Smits pierre.sm...@gmail.com
Subject: Re: move to git.
Quoting:
We are also prepared to be assertive regarding this situation.
SNIP
Thanks Ean for the position of *Brainfood* in this position. It comes
across as 'Do it our way, or else'. You are free to make such statements
and when followed through there will be consequences. For all participating
in this project. One I can see standing out clearly is: no more
participation in/contribution from the employees of Brainfood and from the
other companies in that consortium back into the project.
If that is going to happen, I will say: 'I thank you for all the
contributions you did to the project'. And I will check in my sentiments at
the door. I do hope that if you do you also resign totally from this
project.
I believe what I said was we'll do it our way even if you continue to do it
your way. I'm not sure what the or else part of my message was. I would ask
you to explain that to me but I'm not sure its important to the discussion.
I rather have the community comes to its decision based on sound/valid
arguments, not (veiled) threats.
There were no threats in my message. A threat might read like no participation
in/contribution from {insert group here} will be allowed if they try to do
something without my permission.
The Apache Way is to be nice and I think it would be nice if people could
pursue their own ideas about how to improve the project as long as they do not
coerce other members.
Re: move to git.
- Original Message - From: Jacques Le Roux jacques.le.r...@les7arts.com Subject: Re: move to git. Like Adrian and mostly for the same reasons, I don't believe we need Git. But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this possibility. I disagree. It is useful in many situations for OFBiz developers to create a local repository that is not globally shared. Some customers may even require such a situation for security or legal reasons. Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then hard to review and too late to share ideas. So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1 if necessary! We are also prepared to be assertive regarding this situation. If the project does not move to GIT then Brainfood is willing to participate in a consortium of organizations that will peer with each other to share updates to the master branch for their local OFBiz repository. Such an arrangement will, effectively, result in a distributed master repository image. If anyone else is interested in such an arrangement please feel free to speak up and we can begin the planning process.
Re: NIO and Tomcat COMET communication
Not to be crass, but, let me Google that for you: http://en.wikipedia.org/wiki/Comet_(programming) - Adrian Crum adrian.c...@sandglass-software.com wrote: It would help if we knew what COMET is. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: NIO and Tomcat COMET communication
I agree that we would want to revisit the auto-update feature. The notion of an interval may be obsolete because the data would get pushed when the change occurs rather than polling for it. That is the reason that NIO is required, so that the new Tomcat CometEvent classes can be used. They do not function with the standard HTTP connector. We could also implement websockets under Tomcat and gracefully fall back to long polling if the browser doesn't support them. Even IE does them as of IE9 so we wouldn't exactly be putting ourselves on the bleeding edge by supporting them. - Jacques Le Roux jacques.le.r...@les7arts.com wrote: +1 for NIO It seems more than auto-update-interval and auto-update-target attributes would be provided, Ean? BTW it would be good if we added an example of use of auto-update-interval and auto-update-target Also I stumbled upon this recently http://www.w3schools.com/html/html5_serversentevents.asp unfortunately only real browsers support it https://imgur.com/H4lcN ;) -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
NIO and Tomcat COMET communication
I have just finished up a COMET communication servlet and services for OFBiz. In order to support COMET I had to enable the NIO protocol in the Catalina container. From what I have seen, NIO works for all the OFBiz screens I have tried. I don't think that adding the NIO support should cause any problems but I also wonder if we shouldn't make the NIO adapter the default for performance reasons. I'm going to open a ticket with the patch but I also thought I would start the discussion. I will make the servlet component and its services available as a branch on the Brainfood git repo. I am using it to drive dynamic order screens on an AJAX oriented financial platform we have built on top of OFBiz. The display technology is a big departure from the way OFBiz screen handlers work but I think some aspects of what I'm doing can be retrofitted onto OFBiz screens, even if it is as simple as triggering a page refresh when certain entities are updated. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: The official demos are back
Great news! - Jacques Le Roux jacques.le.r...@les7arts.com wrote: I'm happy to announce that eventually all the demos are back. The main page is updated to reflect that: http://ofbiz.apache.org/ You can also get to the trunk demo using http://demo-trunk-ofbiz.apache.org/ecommerce/control/main http://demo-trunk-ofbiz.apache.org/catalog/control/main?USERNAME=flexadminPASSWORD=ofbizJavaScriptEnabled=Y Two things which are worth to be noted have changed. 1) The sub domains are no longer demo-*.ofbiz.apache.org but demo-*-ofbiz.apache.org 2) Internally OFBiz no longer uses HTTPS in these demos. The security is done by the infra team which is proxying all calls. The official ASF certificate is used for all demos. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
[jira] [Created] (OFBIZ-5620) Main website javadoc link is broken
Ean Schuessler created OFBIZ-5620: - Summary: Main website javadoc link is broken Key: OFBIZ-5620 URL: https://issues.apache.org/jira/browse/OFBIZ-5620 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: Release Branch 11.04 Reporter: Ean Schuessler The Javadoc link on the main website is broken. This is probably very discouraging for potential users. What do we need to do to get it fixed? Is it an Apache infrastructure team problem? -- This message was sent by Atlassian JIRA (v6.2#6252)
Separation of concerns in the ControlServlet
In our internal development we have been working to keep our app logic inside services and not let it leak out into the web action code. In general, we're basically working to eliminate the use of code in the actions and move it all the way out to client side javascript. By the time the client talks to OFBiz in our current work it is typically the direct invocation of a service. One challenge we have noticed is dealing with cookies and session attributes. We are thinking that it is an oversight that the Controller allows a service to read from parameters and session values but does not allow it to write back to them. If the mode is OUT and the session-attribute-name value is set then the outbound value should be written to the session. If this was expanded to allow cookie and localStorage values then most interactions could be reduced entirely to service invocations. We talked about opening a bug for this but thought that it might make sense to discuss it and clarify the idea with a little group discussion. There are some additional changes we would like to see for adding the HTTP method as part of the binding for service invocations. For instance: /profile + GET = read a profile /profile + PUT = create new profile /profile + POST = update a profile /profile + DELETE = delete a profile ... etc... This would allow better support of RESTful client side technologies like Backbone.js. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
[jira] [Commented] (OFBIZ-4274) Implement a REST Servlet
[
https://issues.apache.org/jira/browse/OFBIZ-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13959293#comment-13959293
]
Ean Schuessler commented on OFBIZ-4274:
---
Great stuff. What would you think about supporting cookie and session values
as well?
ie. service-param name=sessionId value=${_SESSION.sessionId}/
It would also be useful if services could update session and cookie values.
We will play with this code.
Implement a REST Servlet
Key: OFBIZ-4274
URL: https://issues.apache.org/jira/browse/OFBIZ-4274
Project: OFBiz
Issue Type: New Feature
Components: framework
Reporter: Adrian Crum
Priority: Minor
Attachments: RestExampleSchema.xsd, RestXmlRepresentation.xml,
rest-conf.xml
Implement a REST servlet that will map REST requests to OFBiz services.
Details are in the comments.
[here is the discussion which took place on the dev
ML|http://markmail.org/message/ai6q2fbksowaayn4]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
ApacheCon
I have some business in Los Angeles and may consider coming through Denver to meet with people. I'm not particularly interested in paying $700 for ApacheCon because I feel that the price is too high. Sorry if that seems unsupportive. How many people will be in town for ApacheCon and would there be an interest in putting together a BoF or dinner or something? -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: ApacheCon
Well, I hate to ask for special treatment but thanks! (I still think ApacheCon is overpriced. Could we get FOSDEM US? Hello, Portland? Someone?) - Anil Patel anil.pa...@hotwaxmedia.com wrote: Please talk to Mike, He may have a pass that he can give you. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Brainstorming: merging application components
- Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: I think I already mentioned this in the past, and I know it may sound a bad idea. Also, this is not really a proposal, just an imperfect idea that needs to be better defined. However I think it makes sense to share this with you in order to get some feedback. Idea: merge all the application components into one (ofbizerp or similar). This component will have all the entity definitions, all service definitions and their implementations and will also have all the webapps. Quite the contrary I have often wished that there was a way to get a minimal version of the entity and service engine. I think if we were judicious in the use of entity inheritance (ie. Party - Person, etc.) that we could have a baseline layer that can run with very little code. Much in the way that JDK8 had to face the modularity demon, I believe that eventually stacking things together will eventually become a problem. At some point that baseline will simply become too large and imply too great a start-up time and utilize too many resources for many types of projects. Look also at what Red Hat has done with the start up time of WildFly. That is inspirational. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: The future of OFBiz - Open Discussion
- Pierre Smits pierre.sm...@gmail.com wrote: Re: I welcome the suggestion made by David to have each of us explain our own motive for participating in this project. We use OFBiz because it is the most mature Free Software solution we have found for dealing with real e-commerce that has inventory and manufacturing needs. We no longer use OFBiz as a solution for the presentation or content management layer because we feel its capabilities in that space are outclassed by other solutions. We are starting to do a lot more mobile and HTML5 based interfaces that rely on OFBiz for handling the underlying business processes. The combination of the license and capabilities are our motivations for using the tool. We also have a lot of experience with the OFBiz internal structure and are hesitant to start over. Our current focus is on building solutions around the tool rather than trying to innovate in the tool itself. The capabilities we utilize in OFBiz are well established so we have not had to make many general purpose modifications. We have also become much more aggressive about mashing up the best of breed to achieve solutions rather than trying to duplicate capabilities from scratch. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: The future of OFBiz - Open Discussion
- Paul Piper p...@ilscipio.com wrote: I am not biased against HWM, but what I question is the objectivity that is currently used within this project. As an open source software, you would assume that this project is run by the community - as often claimed by anybody within the PMC. If you look at the current list of members and there personal relations, I would argue that there is at least a conflicting perspective: PMC Members with HWM background * Jacopo Cappellato (V.P. Technology - Hotwax Media) * Scott Gray (Developer - Hotwax Media) * Bilgin Ibryam (Former Hotwax Developer) * David E. Jones (Former CTO Hotwax Media) * Anil Patel (COO Hotwax Media) * Ashish Vijaywargiya (Vice President of Operations at HotWax Media) * Andrew Zeneski (former CIO Hotwax Media) --- Other PMC members * Adrian Crum * Hans Bakker * Jacques le Roux * Erwan de Ferrieres * Adam Heath * David Welton I suppose the conspiracy at work here is the same flavor of conspiracy that dominates the development of the GCC compiler or the Linux kernel. One might look at these efforts and conclude that there is a conspiracy on Red Hat's part to control these software systems. It is true that Red Hat has conspired to create a vast organization with influence in many corners of the globe, however, I believe that a more suitable label for this conspiracy is commercial success. A protracted discussion about why the most visibly successful implementer of the project's software holds unfair sway doesn't strike me as productive. If you want to change that, go back to building your business and hire more firepower than they have. All of us will benefit. As David Jones readily demonstrates, if you have new ideas you can always write new code. Moqui is a more powerful statement than anything you can say on a conference call. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: [jira] [Comment Edited] (OFBIZ-4952) BIRT Web Viewer Integration
It would be nice if we had the ability to partition the classloader of some components. They are always shared currently, correct? - Chatree Srichart (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/OFBIZ-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892274#comment-13892274 ] Chatree Srichart edited comment on OFBIZ-4952 at 2/5/14 4:21 PM: - Hi Jacques, In my experience, some of jar files are related. If we update some of them, they might conflict to others. What I did was I updated all jar files which were from the same version of BIRT runtime . I don't know whether the files you want to update are related to others or not. So, the safe way is to update all files which are from the same version of BIRT runtime . I am glad to know you would be interested to continue on BIRT. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: [jira] [Comment Edited] (OFBIZ-5040) Backend widget application HTML clean-up
I disagree. Freemarker is, itself, a custom technology and one of dwindling popularity. If we insist on using server side page templates then maybe we should be looking at http://quercus.caucho.com/. You may think I'm nutty but consider that we could write an adapter layer for Magento templates. I'm convinced that the system needs to be separated into two layers, a business logic core and a separate interface rendering layer. Even if we have a server side rendering mechanism it should have the same access parameters to the core as a remote swing or Javascript application. In other words, the web actions that have privileged access to global static class and so on need to go. The business logic that is trapped in those web actions is tightly coupled with the specific HTML presentation they are linked with and can't be reused elsewhere. In fact, one of the biggest challenges we have is that the existing UI code makes extensive use of direct delegator calls to render the interface but the delegator is not available remotely for obvious security reasons. How is another view technology (dynamic javascript, swing, whatever) supposed to achieve the functionality that the existing UI provides? You have to rewrite everything as services and many of those services don't exist because the UI is using delegator access instead. Am I making any sense here? - Paul Piper (JIRA) j...@apache.org wrote: That i can understand, jacques. And realistically speaking there is no way we can easily get rid of all the widgets anyhow. But you cannot enforce the use of a custom technology on the masses, nor should you in my opinion. People won't even be using our macros alot, but that's not a problem: The idea is for us to provide a framework that people can use to adapt. The easier we make it for them, the more we are reaching that goal... -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
[jira] [Commented] (OFBIZ-5522) Introduce websocket usage
[ https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886632#comment-13886632 ] Ean Schuessler commented on OFBIZ-5522: --- I don't feel that it makes sense to compromise the functionality for the vast majority of users in order to support a small (and getting smaller) group of odd balls who refuse to update. We are supporting IE8 on production websites using rivets and not seeing problems. IE7 is a problem but, let's face facts, IE7 has plenty of problems and it would be nice to see it go away. Windows Server 2008 shipped with IE7 and it is not EOL until 2018 but exactly what sort of customer is using their ERP system on a Windows Server 2008 system that could not have its browser upgraded? Introduce websocket usage - Key: OFBIZ-5522 URL: https://issues.apache.org/jira/browse/OFBIZ-5522 Project: OFBiz Issue Type: Task Components: framework Affects Versions: SVN trunk Reporter: Jacques Le Roux Priority: Minor After a discussion with Ean, was suggested (draft here): You need a service that lets you subscribe a widget to an entity and then propagate change events to the widget as the entity is modified. A generic mechanism like that could eventually expand to be a general purpose data bound widgets system that mostly looks like the existing system but magically reflects updates. Could be used with/for * The entity cache and webforms to automatically update views when data changes. * Replaces the current system notes * Create a dashboard type pages (to be discussed futher) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OFBIZ-5522) Introduce websocket usage
[ https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886822#comment-13886822 ] Ean Schuessler commented on OFBIZ-5522: --- That's a rather odd graph since it unifies all the Chromes and all the Firefoxes but not the IEs. I guess its because of the feature disparities between the versions of IE. One important consideration with all of this is that websockets have quite variable availability across these browsers as well. That is probably a larger consideration than the ECMAScript issue. I think its really about identifying the browsers we want (need) to support and then building test cases to validate functionality. Personally I would throw IE7 and IE8 off the bus when it comes to designing forward. Those browsers are dead and virtually gone so letting their limitations influence the client design for the coming years doesn't make a lot of sense. Introduce websocket usage - Key: OFBIZ-5522 URL: https://issues.apache.org/jira/browse/OFBIZ-5522 Project: OFBiz Issue Type: Task Components: framework Affects Versions: SVN trunk Reporter: Jacques Le Roux Priority: Minor After a discussion with Ean, was suggested (draft here): You need a service that lets you subscribe a widget to an entity and then propagate change events to the widget as the entity is modified. A generic mechanism like that could eventually expand to be a general purpose data bound widgets system that mostly looks like the existing system but magically reflects updates. Could be used with/for * The entity cache and webforms to automatically update views when data changes. * Replaces the current system notes * Create a dashboard type pages (to be discussed futher) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OFBIZ-5522) Introduce websocket usage
[ https://issues.apache.org/jira/browse/OFBIZ-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13885989#comment-13885989 ] Ean Schuessler commented on OFBIZ-5522: --- I would like to propose the adoption of Backbonejs.org as the client side event distribution mechanism. Introduce websocket usage - Key: OFBIZ-5522 URL: https://issues.apache.org/jira/browse/OFBIZ-5522 Project: OFBiz Issue Type: Task Components: framework Affects Versions: SVN trunk Reporter: Jacques Le Roux Priority: Minor After a discussion with Ean, was suggested (draft here): You need a service that lets you subscribe a widget to an entity and then propagate change events to the widget as the entity is modified. A generic mechanism like that could eventually expand to be a general purpose data bound widgets system that mostly looks like the existing system but magically reflects updates. Could be used with/for * The entity cache and webforms to automatically update views when data changes. * Replaces the current system notes * Create a dashboard type pages (to be discussed futher) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: OFBiz In 2014
Yes. I do have interest in the UI approach. You might just call it client UI refactoring. - Jacques Le Roux jacques.le.r...@les7arts.com wrote: Ean should I create a specific section for this feature (please name it), and would you be interested to help? -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: OFBiz In 2014
I can help refit the existing widget templates. However, As I said in my message, we are much less focused on server side generation these days. It may be interesting to approach this as a bridge where we begin to layer dynamic AJAX functionality more aggressively onto the existing widgets. - Jacques Le Roux jacques.le.r...@les7arts.com wrote: Maybe 2 sections, if you would want to extend your effort with Boostrap? The idea is to gather work force, you should not be alone. Jonatan for instance also expressed an interest about this feature http://markmail.org/message/i7fnxid55cq5uiiz Adrian suggested that an external framework would not be necessary but it seems he spoke only about ecommerce I think we should think also (only for now?) about backend -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: [jira] [Assigned] (OFBIZ-5040) Backend widget application HTML clean-up
http://getbootstrap.com/ - Jacques Le Roux (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/OFBIZ-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-5040: -- Assignee: Jacques Le Roux Backend widget application HTML clean-up -- Key: OFBIZ-5040 URL: https://issues.apache.org/jira/browse/OFBIZ-5040 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Reporter: Paul Piper Assignee: Jacques Le Roux Labels: html, webapp, widget, widgetrendering I am sure that this is a common thing to know: the current backoffice application relies heavily on widgets. This is good, but the current standard-html-structure is not flexible enough and often lacks proper w3c implementation. To make matters worse, you can often find applications avoiding widgets at all and rather overriding the standards with custom ftl implementations. It is these customizations that break the html on numerous screens and make it difficult, if not tedious to create new themes for the backoffice. This task is hence to: * Find a consensus on a new widget standard * Go over each of the application ftls and convert these to the new standard * Recreate the themes and simplify/clean-up special rules Since redoing the theme is a rather large task, we should consider to add an additional css for now which stylises the replacement html instead of working with the old. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
[jira] [Commented] (OFBIZ-5420) Add ability to separately price BOM elements for orders
[ https://issues.apache.org/jira/browse/OFBIZ-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877934#comment-13877934 ] Ean Schuessler commented on OFBIZ-5420: --- This looks very useful. I'm going to try it locally. Add ability to separately price BOM elements for orders --- Key: OFBIZ-5420 URL: https://issues.apache.org/jira/browse/OFBIZ-5420 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: Christian Carlow Attachments: OFBIZ-5420-1.patch, OFBIZ-5420-2.patch, OFBIZ-5420.patch I have a scenario where a company individually prices BOM elements of assembled products ordered. So if an item is manufactured from 2 component products, the company needs to be able to specify prices for both of the components to made up the total parent product cost. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OFBIZ-5420) Add ability to separately price BOM elements for orders
[ https://issues.apache.org/jira/browse/OFBIZ-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877941#comment-13877941 ] Ean Schuessler commented on OFBIZ-5420: --- What version of OFBiz are these patches intended for? I tried to apply them to trunk as well as 13.07 without success. Add ability to separately price BOM elements for orders --- Key: OFBIZ-5420 URL: https://issues.apache.org/jira/browse/OFBIZ-5420 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: Christian Carlow Attachments: OFBIZ-5420-1.patch, OFBIZ-5420-2.patch, OFBIZ-5420.patch I have a scenario where a company individually prices BOM elements of assembled products ordered. So if an item is manufactured from 2 component products, the company needs to be able to specify prices for both of the components to made up the total parent product cost. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OFBIZ-5420) Add ability to separately price BOM elements for orders
[ https://issues.apache.org/jira/browse/OFBIZ-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877999#comment-13877999 ] Ean Schuessler commented on OFBIZ-5420: --- That's probably my problem, let me try again. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com Add ability to separately price BOM elements for orders --- Key: OFBIZ-5420 URL: https://issues.apache.org/jira/browse/OFBIZ-5420 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: Christian Carlow Attachments: OFBIZ-5420-1.patch, OFBIZ-5420-2.patch, OFBIZ-5420.patch I have a scenario where a company individually prices BOM elements of assembled products ordered. So if an item is manufactured from 2 component products, the company needs to be able to specify prices for both of the components to made up the total parent product cost. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OFBIZ-5420) Add ability to separately price BOM elements for orders
[ https://issues.apache.org/jira/browse/OFBIZ-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878068#comment-13878068 ] Ean Schuessler commented on OFBIZ-5420: --- Maybe the solution is product configurations with the ability to override option prices at order time? Add ability to separately price BOM elements for orders --- Key: OFBIZ-5420 URL: https://issues.apache.org/jira/browse/OFBIZ-5420 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: Christian Carlow Attachments: OFBIZ-5420-1.patch, OFBIZ-5420-2.patch, OFBIZ-5420.patch I have a scenario where a company individually prices BOM elements of assembled products ordered. So if an item is manufactured from 2 component products, the company needs to be able to specify prices for both of the components to made up the total parent product cost. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (OFBIZ-5420) Add ability to separately price BOM elements for orders
[ https://issues.apache.org/jira/browse/OFBIZ-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878070#comment-13878070 ] Ean Schuessler commented on OFBIZ-5420: --- For complicated businesses like home building this seems very necessary Add ability to separately price BOM elements for orders --- Key: OFBIZ-5420 URL: https://issues.apache.org/jira/browse/OFBIZ-5420 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: Christian Carlow Attachments: OFBIZ-5420-1.patch, OFBIZ-5420-2.patch, OFBIZ-5420.patch I have a scenario where a company individually prices BOM elements of assembled products ordered. So if an item is manufactured from 2 component products, the company needs to be able to specify prices for both of the components to made up the total parent product cost. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: Tomcat and Websocket
Of course. :-D But also think of such a facility as a stepping stone to the future. Even if the only thing it did initially was drive the system notes display, its really what you want for a lot of things. You need a service that lets you subscribe a widget to an entity and then propagate change events to the widget as the entity is modified. A generic mechanism like that could eventually expand to be a general purpose data bound widgets system that mostly looks like the existing system but magically reflects updates. Dashboard type pages would be an obvious next step after system notes. - Jacques Le Roux jacques.le.r...@les7arts.com wrote: Yes fine, though we have all other priorities ;) -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Tomcat and Websocket
Or, if you were currently looking at a party and someone updated their address that you would immediately see it without reloading. - Jacques Le Roux jacques.le.r...@les7arts.com wrote: Like for instance dynamic messages sent to UI (called -- Last system notes -- on top of OFBiz backend pages) ? Jacques On Sunday, January 12, 2014 8:52 PM, e...@brainfood.com wrote I have played with it some. It would be really fun to do some things with the entity cache and webforms to automatically update views when data changes. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Tomcat and Websocket
I have played with it some. It would be really fun to do some things with the entity cache and webforms to automatically update views when data changes. - Jacques Le Roux jacques.le.r...@les7arts.com wrote: I just upgraded Tomcat. Doing so I spotted tomcat7-websocket.jar and websocket-api.jar (that we have not embedded) I have not worked with Websocket yet, I wonder if someone did? -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: OFBiz In 2014
I agree that we should migrate FTL templates to ofbiz widgets for the sake of consistency throughout the interfaces. However, I do have to say that I would not use form widgets to develop a customer facing site. At this point, Brainfood is pretty much at a consensus that we do not want to do page template oriented development in the server at all. When you look at applications like Google Maps it becomes clear that the send post, alter state, regenerate and send page workflow is incredibly limited. The future seems to look a lot more like applications written in Javascript that generate HTML directly in the browser. So, for us, the important feature is the JSON-RPC interface for this remote applications. It would be genuinely interesting if we could write a client side form widget interpreter that would delegate generation of the interface to the client side and then supply the action interface via AJAX. That is something we would be very interested in. Refactoring the widget generation code to support greater modularity in the HTML could be another target of such an effort. I made some modest efforts towards a Bootstrap based OFBiz theme and I found it difficult to make progress with the current setup. - Gavin Mabie kwikst...@gmail.com wrote: It appears that the citing of Drupal/WordPress/Magento solicited quite a lot of comment. It's a side issue really and whether some houses prefer to integrate existing solutions is besides the point. More importantly, most commentators would agree that theme developement in Ofbiz does require more attention. The vast majority of threads on this ML focuss on backend business rules and processes. That in itself is not a problem - if you regard Ofbiz as a Framework only. It only means that, as far as frameworks go, we need a better framework for theming as well. This will encourage more participation from developers who have more of a front-end orientation. I would support a drive towards better themeability in 2014. In this regard I would like to suggest that we take a look at the VisualThemeResource entity which currently is currently poorly defined. Gavin -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: OFBiz In 2014
Heartily agreed. At Brainfood we also feel it is a better strategy to integrate with those systems than to compete with them. That is the direction we have been moving in with our client development work. - Adrian Crum adrian.c...@sandglass-software.com wrote: I have participated in a number of discussions along this line - beginning with the 2007 developers conference. My perspective back then hasn't changed - instead of trying to make OFBiz more Drupal-like or more WordPress-like, let's leave the job of CMS to existing products and find ways to connect those products to OFBiz. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
[jira] [Commented] (OFBIZ-2820) Pricing for variable size objects
[
https://issues.apache.org/jira/browse/OFBIZ-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859082#comment-13859082
]
Ean Schuessler commented on OFBIZ-2820:
---
It looks like the ability to enter a single amount is there but multiple
arbitrary value features don't seem to be well supported. It would be nice to
have a top level feature amount drive quantities on subassemblies.
Pricing for variable size objects
-
Key: OFBIZ-2820
URL: https://issues.apache.org/jira/browse/OFBIZ-2820
Project: OFBiz
Issue Type: New Feature
Components: product
Affects Versions: SVN trunk
Environment: all
Reporter: Mark Whitis
OFBiz seems to lack support for variable size objects.
Examples:
- 5.36 hours of time at $100 for first hour and $75 per additional hour
billed in increments of 15 minutes.
- 1.7 yards of cloth at $6.37 per yard
- 1.5lb of bulk whole wheat flour at $1.58/pound
- 4 pieces 6 inches long of alloy 6061-T6511 aluminum 1 square bar stock:
- Maximum length per piece: 108 inches
- Pull charge: $0.50
- Cutting charge: 4 cuts at $0.15/cut - may be global or item
specific or calculated based on cross section and material
- Cross section: 1 cubic inch per inch (line item specific)
- Density: 0.098 pounds per cubic inch (shared for all 6061-T6511
products)
- Shape modifier:1.00 for square shape (line item or category
specific) - some shapes may be more expensive per unit weight.
- Shipping weight:
piece_length*number_of_pieces*cross_section*density
- cost per pound: shared with other 6061-T6511 product
- Cost:
pull_charge+cut_charge*number_of_pieces+cross_section*density*shape_modifier*price_per_pound*(piece_length+kerf)*number_of_pieces
The cost of aluminum may change frequently. Price calculation
might be based on the current spot price of aluminum, inventory replacement
cost (same as preceeding), or the cost when these particular bars were
acquired, or some function that takes both into account.
Remainder charges: Since pieces are cut from fixed length bars,
Prices may figure in a surcharge based on the remaining portion that will be
more or less unsaleable and has to be sold as surplus, melted down, etc. Or
alternatively, this can be included in the charge
and a discount offered for full bar lengths supplied as full bar or
cut up. So, you pay a reduced price per inch (or a fixed cost) if you buy
a full bar or if you order a full bar cut to length, etc.
- Full bar price modifier: 0.80.
example: 13 pieces 16 long (+1/8 saw kerf) gets 7 pieces from
the first bar, charged as 1 bar + 7 cuts, and 6 pieces from the second bar
charged by the inch.However, since the full bar price is lower, in this
case, this can be charged as 2 bars + 13 cuts.
Example sites: www.asapsource.com, www.onlinemetals.com,
www.industrialmetals.com.Various levels of dysfunction. ASAP's web
store can handle per inch pricing but can't factor in the cutting prices
properly so they charge greatly inflated (almost 4x what the price should be)
cost per inch.industrialmetals web store can't handle per inch pricing so
they clutter up the website with 12, 24, 36, 48, 60, and 72 standard
lengths of the same item, you have to contact them if you want a different
length, and a substantial portion of their inventory isn't in the webstore
due to the burden of creating six or more products per item (not to mention
having to change hundreds of items * 6 copies when the cost of materials
changs).
- t-slot structural aluminum
This is very similar to the bar stock given above.However, there
is a twist.There are optional standard machining services.
- 4 pieces 32 long of 10EX1020 extrusion
- 1 clearance hole {0.125} diameter measured {0.5} from end
{A} along grove {A}.
- 1 clearance hole 0.125 diameter measured 0.5 from end A
along grove B
-1 clearance hole 0.125 diameter measured 0.5 from end B
along grove A
- 1 clearance hole 0.125 diameter measured 0.5 from end B
along grove B
- 1 customer part number marking: XYZ001
- 2 pieces 32 long of 10EX1020 extrusion
- 1 {clearance hole} {0.125} diameter measured {0.5} from
end {A} along grove {A}.
- 1 clearance hole 0.125 diameter measured 0.5 from end A
along grove B
- 1 clearance hole 0.125 diameter measured 1.5 from end A
along grove A
- 1 clearance hole 0.125 diamter measured 1.5 from end A
along grove B
- (four more
[jira] [Commented] (OFBIZ-2820) Pricing for variable size objects
[
https://issues.apache.org/jira/browse/OFBIZ-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859139#comment-13859139
]
Ean Schuessler commented on OFBIZ-2820:
---
A further complication is the way ShoppingCartItem.java currently creates order
adjustments for amount based features. If I read this correctly, any feature
with an amount specified will end up adding quantity * amount to the order. I
assume this is to support arbitrary value gift cards but it basically prevents
amount based features from being used for anything else. One possibility we
discussed would be adding a customFeaturePriceMethod field that functions in
the same way as customProductPriceMethod. This would allow the default behavior
to be disabled for new code but leave existing users unaffected.
https://github.com/apache/ofbiz/blob/8f890c2fd7de2aa6a087a27622855b2fa2fced7f/applications/order/src/org/ofbiz/order/shoppingcart/ShoppingCartItem.java#L2135
Pricing for variable size objects
-
Key: OFBIZ-2820
URL: https://issues.apache.org/jira/browse/OFBIZ-2820
Project: OFBiz
Issue Type: New Feature
Components: product
Affects Versions: SVN trunk
Environment: all
Reporter: Mark Whitis
OFBiz seems to lack support for variable size objects.
Examples:
- 5.36 hours of time at $100 for first hour and $75 per additional hour
billed in increments of 15 minutes.
- 1.7 yards of cloth at $6.37 per yard
- 1.5lb of bulk whole wheat flour at $1.58/pound
- 4 pieces 6 inches long of alloy 6061-T6511 aluminum 1 square bar stock:
- Maximum length per piece: 108 inches
- Pull charge: $0.50
- Cutting charge: 4 cuts at $0.15/cut - may be global or item
specific or calculated based on cross section and material
- Cross section: 1 cubic inch per inch (line item specific)
- Density: 0.098 pounds per cubic inch (shared for all 6061-T6511
products)
- Shape modifier:1.00 for square shape (line item or category
specific) - some shapes may be more expensive per unit weight.
- Shipping weight:
piece_length*number_of_pieces*cross_section*density
- cost per pound: shared with other 6061-T6511 product
- Cost:
pull_charge+cut_charge*number_of_pieces+cross_section*density*shape_modifier*price_per_pound*(piece_length+kerf)*number_of_pieces
The cost of aluminum may change frequently. Price calculation
might be based on the current spot price of aluminum, inventory replacement
cost (same as preceeding), or the cost when these particular bars were
acquired, or some function that takes both into account.
Remainder charges: Since pieces are cut from fixed length bars,
Prices may figure in a surcharge based on the remaining portion that will be
more or less unsaleable and has to be sold as surplus, melted down, etc. Or
alternatively, this can be included in the charge
and a discount offered for full bar lengths supplied as full bar or
cut up. So, you pay a reduced price per inch (or a fixed cost) if you buy
a full bar or if you order a full bar cut to length, etc.
- Full bar price modifier: 0.80.
example: 13 pieces 16 long (+1/8 saw kerf) gets 7 pieces from
the first bar, charged as 1 bar + 7 cuts, and 6 pieces from the second bar
charged by the inch.However, since the full bar price is lower, in this
case, this can be charged as 2 bars + 13 cuts.
Example sites: www.asapsource.com, www.onlinemetals.com,
www.industrialmetals.com.Various levels of dysfunction. ASAP's web
store can handle per inch pricing but can't factor in the cutting prices
properly so they charge greatly inflated (almost 4x what the price should be)
cost per inch.industrialmetals web store can't handle per inch pricing so
they clutter up the website with 12, 24, 36, 48, 60, and 72 standard
lengths of the same item, you have to contact them if you want a different
length, and a substantial portion of their inventory isn't in the webstore
due to the burden of creating six or more products per item (not to mention
having to change hundreds of items * 6 copies when the cost of materials
changs).
- t-slot structural aluminum
This is very similar to the bar stock given above.However, there
is a twist.There are optional standard machining services.
- 4 pieces 32 long of 10EX1020 extrusion
- 1 clearance hole {0.125} diameter measured {0.5} from end
{A} along grove {A}.
- 1 clearance hole 0.125 diameter measured 0.5 from end A
along grove B
-1 clearance hole 0.125 diameter measured 0.5 from end B
along grove A
- 1 clearance hole 0.125 diameter
Re: Discussion: Moving to Java 7
I've also had good luck running on Java 7. - Jacques Le Roux jacques.le.r...@les7arts.com wrote: I think it's safe to move over to Java 7 without any changes. I have run OFBiz locally - dev mode - for a long time using Java 7, until recently where I moved back to Java 6 for other reasons. What will be quite interesting is moving to Java 8, which IMO, we should consider ASAP as it will be available. Then much more changes can be envisionned... -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Solr in OFBiz for ecommerce propducts indexing
Components could each have a file that gets sourced into the startup script so that they can participate in the command construction. - Jacques Le Roux wrote: Hi devs, I have adapted Solr to work in specialpurpose at https://issues.apache.org/jira/browse/OFBIZ-5042#comment-13722431 I have one question, about Solr home (see point1 in comment above). Would you be OK to use my last suggestion (Putting -Dsolr.solr.home=specialpurpose/solr as JVM arg, even it it's not used is not really a problem)? Thanks Jacques -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Solr in OFBiz for ecommerce propducts indexing
Ah yes. I'm just thinking shell. I'm sure you could do something like that with a batch file but I don't know how. Never mind. :-D - Jacques Le Roux wrote: What do you mean or envision exactly by a file that gets sourced into the startup script, in other words, how would you do that? I consider ant, bat and sh -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: similar components with different names
Do you really want per-tenant hot-deploy directories? - Hans Bakker wrote: Thanks Scott for you reply, perhaps not explained good, another try: Presently we can write: component://order/widget/order/.. Would be nice if we could also write: component:/widget/order/.. which should be translated into: component://order/widget/order/.. when the url was physically located within the order component. When we have this ability and then rename the order component to something else in ofbiz-component.xml Then this renamed component would still work and can operate in the same system as the original order component. The reason we want this is, that we create sometimes modified components for different customers which should work in the same SAAS multi tenant environment. bit more clear now? -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: similar components with different names
I don't know that I would say that. You could have a set of implementations that all map into a particular namespace and have different customers select different combinations on a user by user basis. That flexibility would actually let you run a larger set of customers on a single shared infrastructure rather than forcing you into setting up special case servers just to allow those overrides. - Scott Gray wrote: Not really SaaS once you start heading down that road huh. Personally I'd focus on designing for the 90% and if necessary, improving the framework to get customizations for the 10% into the db. Regards Scott -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Plan for the creation of the new branch (13.04?)
Clearly I'm feeling some guilt about not helping with releases. :-D Thanks for clarifying. - Jacopo Cappellato wrote: I was actually referring to Hans, because I was surprised that he was trying to influence the way we were preparing our release after he clearly mentioned in several occasions that he was not interested in releases... but the discussion is now resolved after we realized there was a misunderstanding. I was not chastising you for not being involved with release management and your point of view is always welcome. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Plan for the creation of the new branch (13.04?)
- Jacopo Cappellato wrote: please also consider that who is pushing to keep this component in the release until now has shown zero interest in releases and did not help the community to maintain them or publish them or respond to vulnerability reports. I stand suitably chastised. Please consider my observation withdrawn. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Plan for the creation of the new branch (13.04?)
I have to concur that the reporting feature feels core to me for business users. BIRT seems to be the most widely accepted standard since Jasper has gone freemium and BI seems like a huge selling point for us if we get it right. I do have issues with the way BIRT is integrated (which I can elaborate separately). In some cases I run the stand-alone BIRT servlet directly. I don't know whether this makes a case for pulling BIRT out or keeping it in. I suppose what I'm saying is that reporting really needs to be present out of the box for us to make a compelling business case for the system. - Hans Bakker wrote: Jacopo, As was discussed often before, we at least now have a standard reporting system included in the system which was moved from the framework without my agreement. I think this is an essential part of an ERP system and a framework component. So does it matter that I, as a PMC member with over 2000 commits, do not agree that the Birt reporting system (and sure later the Help system) is not included in the release and said this pretty often? probably not -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Some ideas for the future of the OFBiz
I'm not so much suggesting a beginner mode as I am suggesting that controls be scoped to the role of the logged in user. It just doesn't make sense to show controls that link to screens that the user does not have access to. A side-effect of this would be that an order entry user would have greatly simplified screens. - Paul Foxworthy wrote: Hi Ean, I am absolutely 100% in agreement that the user experience is a big barrier to entry for OFBiz. I am comfortable with Javascript being part of the primary user interface, provided there is architectural provision for alternatives. I do not think that a limited beginner mode is the answer. See the thread at http://ofbiz.135035.n4.nabble.com/hiding-functionality-in-ofbiz-td3473417.html for some discussion on this. Cheers Paul Foxworthy -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Some ideas for the future of the OFBiz
I would like to see a deep refactoring of the UI. Ideally, it should be separated into two distinct components, a view renderer and a series of authenticated services that support it. It is about time for us to step into the modern world where the UI is an application, written in Javascript, that communicates with the application using JSON or XML RPC calls. If rendering for javascriptless clients is really still a priority then we might want to look at using rhino or nashorn in the server to do the same rendering there but, fundamentally, move to a javascript based view rendering solution. The interactivity and fluidity of a properly AJAX based interface is part of what makes us look so dated compared to solutions like OpenERP. We also need to completely reconsider the UI experience. The interface is overwhelming to new users. If we could have a role based method for hiding controls then we could have a beginner user mode that greatly simplified core screens. A basic drop-ship ecommerce user doesn't need to see billing accounts, facilities and a lot of the other complexity on the product screens. Our order entry process is also rather clunky, even in comparison to older systems like SQL-Ledger. - Jacopo Cappellato wrote: Hi all, this is just intended to brainstorm some ideas for the future OFBiz (let's say for the 14.04 branch) and to get the community feedback... I don't have concrete plans at the moment for most of them Some of the ideas below are intended to renew some core parts of the OFBiz Framework, replacing custom code (some of getting old) with Open Source alternatives; some of them are just cleanups. * Replace the OFBiz TX Manager and the Database Connection Pool (Geronimo TX and DBCP, well... they actually can stay as optional components) with: http://www.atomikos.com/Main/TransactionsEssentials (see initial work on https://issues.apache.org/jira/browse/OFBIZ-5129 ) * Refactor the OFBiz Security (authentication/authorization/cryptography) with (a session I attended during ApacheCon@Portland inspired me for this): http://shiro.apache.org * Replace Javolution (this has been already discussed in the past) * Replace the OFBiz cache system with: http://ehcache.org * Replace the OFBiz job scheduler with: http://quartz-scheduler.org * Reorganize the screen data preparation Groovy scripts into bigger files with methods (they are now individual files); for example, instead of having: applications/product/webapp/catalog/WEB-INF/actions/product/EditProductAssoc.groovy applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContent.groovy applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContentContent.groovy applications/product/webapp/catalog/WEB-INF/actions/product/EditProductFeatures.groovy ... we could have one file: applications/product/webapp/catalog/WEB-INF/actions/EditProduct.groovy with methods: editProductAssoc, editProductContent, editProductContentContent, editProductFeatures... (note: this switch is possible since the enhancements we did one year ago); this could make our code more readable and organized without loosing the ability to override individual scripts from hot-deploy components; in the process, we could also review the scripts and clean them or improve (some of them are pretty old) * (in the process) we could also refactor the code of the Groovy scripts to use the (now experimental and to be tested/expanded) DSL methods we implemented one year ago Kind regards, Jacopo -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Meetings in Portland
I have a customer meeting the same week. :-( - Jacopo Cappellato wrote: Hi all, the next week I will be in Portland for ApacheCon: if there is anyone attending the conference or just in the area who would like to meet and chat about OFBiz or whatever, please send me an email directly, I would be happy to spend some time together and share ideas. Regards, Jacopo -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: [VOTE] [RESULT] Apache OFBiz 11.04.02
I think Adam's point was that someone could synthesize a vote from you (or, more importantly a vote from a mostly dormant member like Adam) and get something to pass. Since, in practice, this kind of thing doesn't ever seem to happen its probably not worth worrying about but his point is still cogent. - Jacopo Cappellato wrote: On Jan 17, 2013, at 7:39 PM, Adam Heath wrote: Ie, how many total voters are there? Everyone in the World can vote, we need at least 3 positive votes from PMC members... I would recommend you to read the ASF voting guidelines. Regards, Jacopo -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Comparing with OpenERP
Some confusing things there. Most strangely, 4,909,882 lines added in the last 30 days yet 679,749 lines total project size? Something seems to be amiss. To me, we should be creaming these guys on the AGPL license alone. I understand that many businesses are small enough to just not care. Business owners with even a moderate legal awareness should be aware that the AGPL could complicate their ability to transition from a proprietary solution to an open one. - Jacques Le Roux wrote: Interesting, notably the numbers of committers https://www.ohloh.net/p/compare?project_0=Open+For+Business+Project+%28Apache+OFBiz%29project_1=OpenERP Of course quantity is not quality, but it seems OpenERP has a better momentum than OFBiz, at the business level, I mean... Jacques -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Slim-down effort: current situation
I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted. I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository. The nice thing about GIT is that the chaff doesn't get into the wheat bucket. - Jacques Le Roux wrote: Because it's possibly easier for committers to follow the work done and not get a big patch at the end. With Git you tend to receive either a burst of patches or a big one, both in one shoot. Then it's hard to review the work done. By steps it's easier I don't use GitHub, I have enough to do with OFBiz patches already... -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Comparing with OpenERP
Agreed. One thing that immediately jumps out is how much of their codebase is in Javascript. That may imply at least two functional teams right there. It makes me wonder if they are approach things as more of a REST/HTTP-RPC server written in Python that services a client written in JavaScript. I have been approaching most of my recent development efforts this way and I have to say that it allows you to create interfaces that are far more compelling. This shiny object phenomena may explain some of their popularity. One thing waiting in the wings for Java are the new Nashorn JavaScript capabilities coming in JDK8. It may be worth considering a more aggressive adoption of JavaScript, especially in the widget code. If we begin to write things like form verification in JavaScript we could share code between the client and server and do things like giving the client immediate feedback when entering form data. - d...@me.com wrote: On Jan 5, 2013, at 2:10 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: I'm not quire sure what you mean, but anyway I don't sell OpenErp ;) My primary intention was just to note that they have much more committers(?) doing much more commits(?) When you look into details numbers are certainly misleading: https://www.ohloh.net/p/openerp/contributors?page=47sort=latest_committime_span=12+months (a lot of committers with only few commits) So yes, maybe not the right tool for that... Or at least would need more research in it... I'm not sure if they do this, but that number of committers only really makes sense if there are different groups working on different things, or if 90% of the committers are only very rarely involved. If OFBiz turned into more of a series of projects (ie with addons and such) instead of a single big project, that would probably work much better. -David -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Slim-down effort: current situation
Why wouldn't they just fork and then issue a pull request on GitHub? - Jacques Le Roux wrote: I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)? http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: OFBIZ-4872: webdriver integration
Maybe more of this work needs to be done in feature branches? You can make the argument that SVN (at least as far as I know) encourages an everything goes in the central repository work flow because it doesn't have the GIT distributed workflow. We certainly don't want to discourage new and adventurous development because that is the road to fossilization but, on the other hand, we definitely don't want every wild idea just going into upstream and turning it into a big mess. In the GIT workflow, these changes would be made in someone's fork and they would issue a pull request. Reasonable criticisms about style or architecture would be addressed and then the work would be pulled in as a whole when it reaches a certain level of quality. This is an important topic. Its basically the same issue that provoked David to go create the Moqui framework. Evolving the platform while keeping architectural coherency and stability is not easy. I do think we need to pursue this app store concept and find a way for plugins to be a major part of how we add features. Adding these features in needs to be as easy as clearing the cache in Webtools so that implementors do not feel like they are a second class citizen just because their code isn't in the core upstream repository. If we figured that out properly we might want to jettison A LOT more stuff from core. - Scott Gray wrote: One thing I'm starting to get tired of is contributors (and committers) beginning major works without a thorough discussion about the suitability of the work for OFBiz before starting. I find it frustrating that reviewers are then forced to review under some sort of urgency because it is ready to commit and also made to feel like the contributor's time has been wasted if there are any major issues/disagreements with the design decisions made in the work. In regards to Jacques, I also find it frustrating that he encourages and actively participates in this behavior without actually really performing much in the way of design review other than a generic does it seem like a good feature? test. Don't get me wrong, encouraging contributors to contribute is a great thing and Jacques does an amazing job interacting with the community as a whole but whenever a major work is undertaken without prior discussion then the contributor is taking a big gamble and they should be made well aware of that before starting. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Slim-down effort: current situation
Adam and I have been talking about a feature like this for a while. Its a good question whether something like Maven would serve as a good basis for resolving dependencies or maybe even a pluggable architecture. On Red Hat and Debian systems you could even automatically bring in native dependencies like Memcached, Varnish, NGINX, etc. and provide turn-key configuration of what would otherwise be a very complicated installation. Its also interesting to see how Puppet handles some of these problems. - Jacopo Cappellato wrote: On Nov 16, 2012, at 3:28 PM, Olivier Heintz wrote: It's to decrease the number of step to install, to help people (IT user, not end user I know) Right, in fact Paul and I agree that an OFBiz Plugin Manager would be a nice to have tool but not mandatory to use external tools. Regards, Jacopo -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Job Manager
Yeah, that's not going to fly. Its interesting to note that David Jones replaced the JobPoller with Quartz in Moqui. - Adrian Crum wrote: 3. There is a JobPoller instance per delegator, and each instance contains the number of threads configured in serviceengine.xml. With the current max-threads setting of 15, a multi-tenant installation with 100 tenants will create up to 1500 threads. (!!!) A smarter strategy might be to have a single JobPoller instance that services multiple JobManagers. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: My vision for the OFBiz Framework
To me the convenience is being able to program to a straight AWT like
interface. It is just so convenient to be able to do things like:
myButton = new Button(Click Me, new Button.ClickListener() {
public void buttonClick(ClickEvent event) {
myLabel.setValue(You clicked my button); // simple stuff like this
dispatcher.runSync(SetPartyRole, [roleTypeId: 'BUTTON_CLICKER']); // or even
things like this
}
});
The process of binding these events to URLs to trigger services and worrying
through AJAX processing just falls away. I could add a dozen buttons to a page
and concentrate on the logic they trigger instead of a pile of oddly named
events and url bindings. Sure there is some memory overhead there, sure it has
state but man does it make some things easier.
I think your answer (as I've illustrated above) makes perfect sense and you can
definitely just trigger a service engine from these other frameworks. However,
I've wondered for a while why we couldn't construct stateful graphs of UI
objects from the XML widget descriptors and have the event bindings attach
directly to the widgets.
- David E Jones wrote:
That's a tough one. I just did some research on Vaadin, and in some ways it
looks similar to Wicket, and I suppose in some ways similar to JSF as well,
though Vaadin appears to be a sort of extension to GWT and the unlike Wicket
where the Java code is mostly run on the server (if I understand right) in
Vaadin most of the Java code is transformed using GWT and run on the client,
turning the client into almost a desktop app that communicates with the
server to mostly pass data around.
How to get any two technologies like these to work together is a good
question, or at least how to get them to work together seamlessly. Say you
want to write part of your app in Vaadin and part of it in Wicket... how will
you get them to work together well? I think the answer is that you could have
them both deployed in the same webapp, and pages written in each could link
to each other, but sharing decoration (except by including the same text or
using a tool to interpret a template that they can both include) and
navigation and such would be a nightmare.
In Moqui, like in OFBiz, most of the web UI stuff is based on writing to a
writer or stream and being able to assemble various pieces of text to create
a single web page. Without getting into lower level code, I looked at each of
these three (Vaadin, JSF, and Wicket) and it does not look like they have a
way to generate text to be included in a web page, and perhaps worse handling
navigation and links is so ingrained in the way the tools are designed that
nothing there could be shared (not in ways that I could find, though of
course with enough creative coding anything could be done in theory).
So, I guess the answer is that just like with OFBiz, with Moqui Framework if
you want to use one of those web UI frameworks then use that instead of the
Moqui XML Screens/Forms, and just use other parts of the Moqui API through
the ExecutionContext that could be inited/destroyed in an event listener
instead of the MoquiServlet (since the MoquiServlet wouldn't be used in that
case), or if desperate you could use the Moqui class for static init of the
ExecutionContextFactory and ExecutionContext.
That parts easy, ie use Moqui API for services, entities, and other tools but
not for the web UI... trying to merge and share artifacts between these kinds
of restrictive UI approaches would be tough. On the other hand, if you can
get plain text out of them, you can include that in any Moqui XML Screen.
I don't think a better solution to this exists. Personally, I blame JSP and
their restrictive nature that has been considered acceptable over the years,
and those sorts of restrictions now seem to bleed into all sorts of web UI
frameworks.
--
Ean Schuessler, CTO
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: My vision for the OFBiz Framework
Hi David, As usual you are a fantastically productive guy. Its a little awe inspiring. :-D Have you given any thought as to how different display technologies like Vaadin, JSF or even Wicket could be accommodated in your framework? Playing with Vaadin has shown me how I wish my views were constructed in OFBiz. ~Ean On 04/02/11 01:09, David E Jones wrote: I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today): http://www.moqui.org/ The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0. At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web controller in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more). Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project. However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called Mantle. To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far. Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it. On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Serialized inventory and the ShoppingCart
That makes sense. So I don't need to touch the OrderItem structure, just create reservations at the same time that I create the order. Adding an array of serial numbers to ShoppingCartItem seems necessary though. Do you agree? On 04/07/11 11:19, David E Jones wrote: From a purely model perspective you should be able to create a OrderItemShpGrpInvRes record for each serialized inventory item. The code side of things in OFBiz might do some funny things, especially with re-reservation of inventory (so that re-reserve code may need to be modified to not touch these records), and you'd have to write a reservation service for this case to use instead of the stock reservation, but beyond that I think everything should work the same with the standard reservation records and such. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Serialized inventory and the ShoppingCart
I may be missing something but it looks like you cannot shop an order for a piece of serialized inventory as part of your shopping cart process. Am I wrong about that? If you have a user walk up with, say, a hard drive or something else with a serial number on it how do you represent that in the cart? Obviously the order doesn't exist yet, but I know that no one else can reserve that inventory (for real) since the user is holding it in their hand. Any thoughts on this one? -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: [jira] Updated: (OFBIZ-4203) Add Quercus to OFBiz in order to handle PHP requests
I'm running a build of Quercus from SVN on a number of sites to support PHP front ends. It works for me out of the box. Do we want a .zip you can drop in hot-deploy or something? (but, yes, Quercus is GPL and you definitely want PHP5 support) - Jacques Le Roux (JIRA) wrote: [ https://issues.apache.org/jira/browse/OFBIZ-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-4203: --- Attachment: Quercus.zip The attached archive does not work OOTB. I think it should not be a big deal to fix it. To test simply unpack in hot-deploy It's a work effort done by Vincent Balade in order to use Quercus in OFBiz. I got it to work at some point (2 years ago) and I know the (big French) company where Vincent works uses it everyday. I recently asked him to have all working from hot-deploy. Because before it was in special-purpose and Quercus has a GPL license. 2 weeks ago he sent me that archive but it did not work OOTB. I had no chances yet to have a close look and to fix the issue. So, if you are interested, I'd really like if you could contribute back the work if you get it working. It's well documented and I believe it should not be more than a couple of hours to have it working in hot-deploy Thanks Add Quercus to OFBiz in order to handle PHP requests Key: OFBIZ-4203 URL: https://issues.apache.org/jira/browse/OFBIZ-4203 Project: OFBizhttps://cwiki.apache.org/confluence/display/OFBTECH/Glassfish+v2.1 Issue Type: New Feature Reporter: Jacques Le Roux Attachments: Quercus.zip This is not intended to be added to OFBiz repository since [Quercus|http://quercus.caucho.com/] is GPL licensed. See also [Quercus: PHP in Java|http://www.caucho.com/resin-3.0/quercus/] There is an [alternative to Quercus: Tomcat also have PHP support|Quercus: PHP in Java]. Unfortunately, so far it's limited to PHP 4. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
[jira] Created: (OFBIZ-4173) ATP requirement generation should look for ORDERED requirements attached to CANCELLED order items.
ATP requirement generation should look for ORDERED requirements attached to CANCELLED order items. -- Key: OFBIZ-4173 URL: https://issues.apache.org/jira/browse/OFBIZ-4173 Project: OFBiz Issue Type: Improvement Components: order Reporter: Ean Schuessler Priority: Minor The createATPRequirementsForOrder method currently subtracts any PENDING requirements from the amount needed to fulfill orders before creating additional requirements. It seems like it would also be useful for this method to look for ORDERED requirements that are associated with CANCELLED order items. This would prevent the system from generating additional requirements for stock that is actually available for allocation to new orders. Is there some kind of race condition or other problem I'm not seeing here? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (OFBIZ-4055) Change Contact List Subscription Process
Would unsubscribeContactListParty be a more consistent wording for signOutForContactList? On 12/14/10 04:46, Chatree Srichart (JIRA) wrote: [ https://issues.apache.org/jira/browse/OFBIZ-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chatree Srichart updated OFBIZ-4055: Attachment: contactlist.patch Changing patch file -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
[jira] Updated: (OFBIZ-4055) Change Contact List Subscription Process
[ https://issues.apache.org/jira/browse/OFBIZ-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ean Schuessler updated OFBIZ-4055: -- Attachment: ean.vcf Would unsubscribeContactListParty be a more consistent wording for signOutForContactList? -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com Change Contact List Subscription Process Key: OFBIZ-4055 URL: https://issues.apache.org/jira/browse/OFBIZ-4055 Project: OFBiz Issue Type: Improvement Components: specialpurpose/ecommerce Affects Versions: SVN trunk Environment: Ubuntu 10.04 Reporter: Chatree Srichart Fix For: SVN trunk Attachments: contactlist.patch, ean.vcf I think the current contact list subscription process is not complete. The current process is when a user enter his/her email address on the e-commerce page for subscribing a contact list. The system will set ContactListParty's status to Accepted. I think that should be set to Pending Acceptance first and wait for a user's confirmation from user's email inbox. Also the system should have a unsubscribe process to expire user's email address from a contact list. I found the unsubscribe statuses in StatusItem entity, Unsubscription pending and Unsubscribed, but they don't be used. I think the processes should following: Subscribe process === 1. The user select a contact list and enter his/her email address 2. The system create a ContactListParty with Pending Acceptance status 3. The system send a verify email message to the user's email address 4. The user confirm the subscribing in his/her email inbox 5. The system change the status of ContactListParty to Accepted Unsubscribe process 1. The use select a contact list and enter his/her email address 2. The system change the status of ContactListParty to Unsubscription pending 3. The system send a verify email message to the user's email address 4. The user confirm the unsubscribing in his/her email inbox 5. The system change the status of ContactListParty to Unsubscribed The both of processes, subscribe and unsubscribe, should also support if the user do not login to the system. I changed following: - create Subscribe Contact List Notification and Unsubscribe Contact List Verify as email type for email settings of product store - create signOutForContactList service for setting a contact list party's status to CLPT_UNSUBS_PENDING - create updateContactListPartyNoUserLogin service to handle updating the contact list party without user login - create sendContactListPartySubscribeEmail service for sending an email message to user after the user confirm the subscription. This email message would contains a button for requesting unsubscribe the contact list - create sendContactListPartyUnSubscribeVerifyEmail service for sending an email message to user after the user request to unscrube. This email message would contains a button for unsubscribing the contact list - add SECA when the createContactListPartyStatus be called with CLPT_ACCEPTED status then call the sendContactListPartySubscribeEmail service to send the subscribe email message. - add SECA when the createContactListPartyStatus be called with CLPT_UNSUBSCRIBED status then call the sendContactListPartyUnSubscribeEmail service to send the unsubscribe email message. - add SECA when the createContactListPartyStatus be called with CLPT_UNSUBS_PENDING status then call the sendContactListPartyUnSubscribeVerifyEmail service to send the email message to verify unscribing. - for starting receive a subscribe, change the contact list party's status from CLPT_ACCEPTED to CLPT_PENDING because the status should be pending before receiving a verify message - create ContactListSubscribeEmail and ContactListUnsubscribeVerifyEmail mail screens - add ProductStoreEmailSetting demo data for productStoreId=9000 with SUB_CONT_LIST_NOT and UNSUB_CONT_LIST_VERI email types - change verifyUrl in the email message's form to updateContactListPartyNoUserLogin because if the user doesn't have a user login then could not view the ecommerce's viewprofile screen. - add preferredContactMechId field to the createContactListPartyStatus and sendContactListPartyUnSubscribeEmail services because I get the contactMechId from ContactListParty instread of UserLogin because these services also be called without authentication. - add Unsubscribe button to Sign Up For Contact List section of the ecommerce's screen for requesting unsubscribing Thank you Regards, Chatree Srichart -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Marketing campaigns and contact lists
Calling it an application seems fine. Is there a good example of an upgradeable multi-table application? - BJ Freeman wrote: how about a contactlistappl that other entities can use in the future change the contactlistid to the contactlistappl. then would also a allow a upfrade path with a service. Ean Schuessler sent the following on 12/12/2010 4:50 PM: Currently, contact lists are associated with marketing campaigns via a contactListId field on ContactList. It seems to me that contact lists would be used repeatedly over a long period of time by numerous campaigns. Would there be an objection to deprecating the marketingCampaignId field in ContactList and creating a new MarketingCampaignContactList entity? I would imagine that this entity would follow the fromDate/thruDate pattern. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Marketing campaigns and contact lists
MarketingCampaignContactList makes more sense to me. It seems in line with tables such as PartyContactMech or ProductStoreCatalog. On 12/13/10 10:33, BJ Freeman wrote: the appl as I understand it is a many to many interface. to my knowledge no one has discussed migration, in detail, as an (semi)automated process but I think it would be a good thread. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Marketing campaigns and contact lists
Currently, contact lists are associated with marketing campaigns via a contactListId field on ContactList. It seems to me that contact lists would be used repeatedly over a long period of time by numerous campaigns. Would there be an objection to deprecating the marketingCampaignId field in ContactList and creating a new MarketingCampaignContactList entity? I would imagine that this entity would follow the fromDate/thruDate pattern. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: duplicate transaction ids for authorized.net
That would suppress the problem, but shouldn't splitting work without being flagged as a duplicate? - Scott Gray wrote: You could try turning off the Split Pay Pref Per Shp Grp option on the product store. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Woop! Confluence data imported into git and displayed with webslinger!
I agree that databases are very, very powerful but they also introduce fundamental limitations. It depends on your priorities. For instance, we've found that the processes companies pursue for editing documentation can be every bit as fluid, complex and partitioned as source code. I'd ask you, as a serious thought experiment, to consider what the ramifications of managing OFBiz itself in a Jackrabbit repository. Please don't just punt on me and say oh, well source code is different. That's an argument by dismissal and glosses over real-world situations where you might have a pilot group editing a set of process documentation based on the core corporate standards, folding in changes from HEAD as well as developing their own changes in conjunction. I've just personally found that the distributed revision control function is fundamental to managing the kinds of real content that ends up on websites. Maybe you haven't. Scott Gray wrote: This isn't about casting stones or attempting to belittle webslinger, which I have no doubt is a fantastic piece of work and meets its stated goals brilliantly. This is about debating why it should be included in OFBiz as a tightly integrated CMS and how well webslinger's goals match up with OFBiz's content requirements (whatever they are, I don't pretend to know). Webslinger was included in the framework with little to no discussion and I'm trying to take the opportunity to have that discussion now. I'm not trying to add FUD to the possibility of webslinger taking a more active role in OFBiz, I'm just trying to understand what is being proposed and what the project stands to gain or lose by accepting that proposal. Version control with git and the ability to edit content with vi is great but what are we giving up in exchange for that? Surely there must be something lacking in a file system approach if the extremely vast majority of CMS vendors have shunned it in favor of a database (or database + file system) approach? I just cannot accept that all of these vendors simply said durp durp RDMBS! durp durp. What about non-hierarchical node linking? Content meta-data? Transaction management? Referential integrity? Node types? -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Woop! Confluence data imported into git and displayed with webslinger!
We think its interesting and handy to manage our web content using GIT.
Its hard to do that with JackRabbit, especially in its preferred
configuration of a database backed store. I think that is a pretty
reasoned explanation. I don't see Adam or I casting stones at your CMS
test application so please consider lightening up. Thanks. :-D
Scott Gray wrote:
To be honest it makes it a little difficult to take you seriously when you
completely disregard the JCR/Jackrabbit approach without even the slightest
hint of objectivity
if (!myWay) {
return highway;
}
The JCR was produced by an expert working group driven largely by Day
Software which has Roy T. Fielding as their chief scientist. While I know
next to nothing about what constitutes a great CMS infrastructure I cannot
simply accept that you are right and they are wrong especially when you make
no attempt whatsoever to paint the full picture, I mean are you suggesting
that a file system based CMS has no downsides? Your approach is filled with
pros and their's all cons?
--
Ean Schuessler, CTO
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: Woop! Confluence data imported into git and displayed with webslinger!
Scott Gray wrote: The main question in my mind is what does all this mean for OFBiz? Obviously because webslinger is currently in the framework you envisage it playing some sort of role in the ERP applications, but what exactly? We see knowledge sharing as an important ERP function. I think I understand better now why Ean and yourself were somewhat negative towards the possibility of a jackrabbit integration, do you see this as some sort of alternative? Some sort of alternative, though I would see Jackrabbit more as an alternative to our modded CommonsVFS+Lucene. I'm mostly antagonistic to a database oriented content management approach because I don't feel like any of the tools out there (including Jackrabbit) realistically deal with the situation of having a long-term development project running in tandem with a live server. All of the database driven tools (Wordpress, Drupal, Joomla, Plone, Alfresco, LifeRay) fail to deliver a solution for distributed revision control. For me, that seems like a critical weakness because I've been through more than a few overhauls of a large corporate information management infrastructure. Work goes on in parallel both in the live server and the development environment. If you don't have tools to manage the process of merging those streams of information then you are in for a tough time. Jackrabbit is very interesting, mostly because it extends the filesystem concept to blend more seamlessly with what the web seems to want its filesystem to look like. I think it would be fully possible for us to replace CommonsVFS with Jackrabbit but I'm not entirely clear that it is worth it. Any CMS that cannot present itself as a vanilla filesystem is fundamentally hampered by the unfortunate reality is that most programs expect to work with that model. I suppose it depends on where you want to be inconvenienced. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Jackrabbit Integration
Adrian Crum wrote: we need is a factory for javax.jcr.Repository, and that could be put in the content component. I would really prefer to not mix components for a couple of reasons: - Some of the existing content stuff should have been in the framework IMO - Mixing old and new in a single component is going to get messy I would really rather see the repository and its associated low level tools become part of the framework. I don't care what we call it, jackrabbit was just the easy choice at the time. I'm trying to understand what we want out of a Jackrabbit integration. The API for accessing OFBiz content is definitely not a comfortable one but I wonder if that isn't more of a reflection of its entities being overly complicated. The DataResource/Content separation has its uses but definitely makes creating content systems less than intuitive. My concern with JackRabbit is similar to concerns I have with Lucene as a search system, which is the disconnection between the layers. It seems like it becomes more complicated to join business data against content once these things are disconnected and that we will end up writing more glue code to bring them back together. When we started our Webslinger work, JSR-283 was not as popular as it is now and we settled on CommonsVFS as a filesystem abstraction layer. I've looked at JSR-283 fairly closely and its an interesting device but has its quirks. Its ability to associate multiple streams of content with a single URL is interesting but departs from the conventional way people think of file systems. Whether this is a bug or a feature isn't clear to me. One of the things that seems very important to me is the ability to have strong file-based content handling because that is the most common mode of data exchange. The WebDAV features of JackRabbit are an interesting possible replacement but I'm not clear that it really represents a full-fledged substitute for file based content management. I wouldn't relish writing a binding for Jackrabbit to the existing content entities though it seems like they could accommodate it. It might be worth looking at the existing JackRabbit JDBC bindings and creating identical EntityEngine entities. That should make a port of the JDBC based back-end to the entity engine straightforward. This would have the benefit of supporting ECAs automatically, maintaining full SQL compatibility and preserving the ability to query content with the entity engine interface. The one significant benefit to wrapping the existing content classes with JackRabbit would be the ability to immediately query existing system content with the easier to manage JackRabbit API. We would have to construct some kind of programmatic namespace to connect in stores, parties and other content to the JackRabbit root but it could make working with the content system much easier. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Hippo CMS
Scott Gray wrote: Not necessarily, OFBiz need only know the location of a given piece of content and how to interact with it. So instead of entities being related to Content records, they would instead have pointers to locations in the content repository. Correct, from the OFBiz side. From the CMS side, the content will be a collection of leaf nodes and the connective structure that organize them will be invisible. That was my point. Queries across these two disparate repositories will also be more painful. The answer to that question is up to the individual, if OFBiz offers a blog, wiki, forum or whatever it doesn't mean that anyone is going to be forced to use it. If any of those things were to be developed it would only be because someone needed it, same as anything in else OFBiz. OFBiz has accounting functionality, but that doesn't prevent anyone from using alternative accounting systems. My point is that JSR-283 doesn't seem to provide mech leverage in terms of actual blog/wiki/forum code. How did you just segue into JSR-286? Hippo CMS is a JSR-286 provider. You're welcome to work on that but it certainly won't be anything I'm going to touch. To borrow from you a bit, our content application is a maze of confusion and dead code. The best I would be willing to offer is migration services for importing data from the Content model into the new repository. I think we are in agreement that a JSR-283 wrapper is a difficult and not terribly interesting thing to pursue. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Hippo CMS
Scott Gray wrote: Well it all really comes down to the question of who gets to define the structure of the content, is it OFBiz or is it the CMS? If it is OFBiz, then will other CMS' be able to consume that structure or will we be left trying to write our own? If it is the CMS, then in order to support more than one CMS, OFBiz would need some sort of mapping mechanism to provide OFBiz developers with a consistent structure to work with. But as I said earlier, I really don't have enough knowledge at the moment about any of this and will need to do more research before I can say anything that isn't based on guesses and hunches. It would be nice if others interested in this did some as well. Any CMS integrated with OFBiz will need to link content items to products, parties, workflows and so on that exist outside of the CMS model. In that sense, OFBiz must define the content model because the root of the content is the OFBiz datamodel and not the other way around. The question is whether the CMS model that is used to control content related to the OFBiz data model should be the same CMS that is used to manage blogs, forums, wikis and other useful goodies. To me, the prime mover in these categories quickly becomes the code controlling the content rather than the data structures because the data structures are fairly simple. Looking at JSR-283 based solutions, one does not see anything even close in terms of popularity to systems such as Wordpress, Drupal or even Roller. With regard to the JSR-286, I think its a maze of confusion and a dead technology. This article sort of sums it up http://today.java.net/article/2009/01/16/jsr-286-edge-irrelevance. Google Gadgets has as much or more these days and yet its adoption is by no means assured. If we really want to switch to JSR-283 as our content interface then I guess the first sensible step would be a JSR-283 adapter on top of the current CMS so that new and old content apps can exist side by side. Once all the existing code is migrated to use the JSR-283 interfaces we could switch out the underlying provider. This would have the added advantage of being able to publish OFBiz legacy content into a JSR-283 environment. Of course, we would still have to work out how to provide ECAs on this new technology and take care of all the other details that the current framework gives us. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Hippo CMS
Jacques Le Roux wrote: I have not much time to comment, but +1 for me, now we need to have enough time and commitment... BTW, who is the CEO at Brainfood? :o) We use a roulette table to make any important decisions though occasionally we dabble in coin flips, the i-Ching and futures markets (the latter being the most error prone). -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Hippo CMS
Adrian Crum wrote: What? No Magic 8 Ball? You can't use those for Open Source projects. They're patented. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: dates in seed xml files are very broken
BJ Freeman wrote: if you got that far it should be all four time fields. however I don't see the need even with sync to do this. If you are talking about the entity sync fields then it definitely seems like the lack of a timezone could cause your sync to fail. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: dates in seed xml files are very broken
Adrian Crum wrote: Actually, this is a bad example - the Staff Meeting temporal expression does not contain a date-time value. A better example would be the recurring jobs that use a Frequency temporal expression. The thing we need to focus on here is the entities that have a fromDate as part of their primary key. If you examine these entries in the seed data you can see that the current fromDates are largely arbitrary (ie. Jan 1st, 2001) and are there only to fulfill the primary key. I believe the point Adam is trying to make is that the moment in time specified in seed data should not wiggle around depending on where the import is run. The sets of primary key values specified in seed data should not cause a duplication if the instance moves across timezones and seed data is re-imported. We should not confuse this issue (primary key value definitions in seed) with specifying actual locally dependent time values (start of business day, etc.). Those locally dependent time values obviously should reflect their current timezone. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: dates in seed xml files are very broken
Adrian Crum wrote: The seed data works fine. It has been working fine for years. It's the process you're using that is the problem. Just because something has been broken for a long time does not mean it is fixed. We have found numerous long-standing problems that simply have never been addressed. I'm sure you have found your share as well. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Dojo tree 1.4
Jacques Le Roux wrote: http://markmail.org/message/g777vmrachizruef Sam and Raj made good points too... Whoops. Sorry to be redundant. Thanks for the pointer! -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Dojo tree 1.4
I think you make a really great point here. JQuery is a utility not a framework and when it comes to utility it really delivers the goods. Looking back to Dojo, I still believe we need something to counter the GWT-EXT threat because users continue to demand an application feel when it comes to ERP. I find Vaadin (vaadin.com) very interesting, if somewhat daunting in scale. It appears to offer the level of abstraction necessary to integrate the screen and form widget systems and is under the Apache License (which makes it very, very interesting). Has anyone else looked seriously at Vaadin? Jacques Le Roux wrote: Looks like we have a good consensus around Jquery so far. I must say that the main arugment for Dojo was its serious. It's a real consistent framework with embedded widgets, not only an API. All those third parties Jquery's widgets (and Prototypes's) are a bit frightening. On the other hand when you want to upgrade to 1.4 you find that it's not as serious as we thought, and I'm *very disapointed* about that. And as those widgets are open source, it's not as frightening as it 1st seems. For instance, we use a third party calendar and we have already poked in (for layered lookups) without issues. At the time we decided to embed Doo and Prototype some pointed also Jquery with good arguments [1] [2][3]. At this time we decided that anyway we were not tied to any Ajax frameworks yet. So yes, +1 for me also, especially now that Sascha wants to tackle it, and I'm sure we will support his effort! Thanks guys Jacques [1] Yoav Shapira in 2006: http://markmail.org/message/ftw7pjfrzxyxmsuz [2] Ean in 2007 http://markmail.org/message/jf5qvxblvrbmtvae (and we know now than when there is a dual licensing we can pick the one we want, here MIT :o) [3] Ean in 2007 http://markmail.org/message/vqjjtribdrulhbl3. When the serious one is less serious than the other (demo in time). Dojo is known to have documentation problems also... Found this link http://www.ajaxdaddy.com/demo-dojo-fisheye.html -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Application names localizations are defined in the CommonUiLabels framework file
We've talked about this a number of times around the office, not only for the application menu but many menus throughout the site. This could allow a party/content binding component to inject menu entries into otherwise stand-alone party and content applications. Sorry if this is a repetition of ideas that have already been discussed. - Bruno Busco wrote: The injectable menu we are speaking about could be the solution. A simple main menu could be defined in the framework with only the Webtools and Example menu entry. Every application could inject its own application menu. An application could also inject menu entries in several different menus so that for example all application's administrations could be placed in one unique high level admin menu entry. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Making the dev process work for me.
If you could make your changes in a cloned GIT repository we might be able to review and commit them en masse. On 05/15/2010 01:45 AM, chris snow wrote: On 15 May 2010 07:38, chris snowchsnow...@googlemail.com wrote: A while back, I had a small improvement committed to provide field tooltip help. I now have the time consuming process of extracting the tooltip help text from the manager references and putting it into the xml property files. The problem is that I have to rely on commiters to take my patches, review and commit them. Erwan is kindly reviewing my patch for the ProductStore and will hopefully commit it at some stage. However, committers have other priorities and getting the huge amount of patches that I will be providing to be committed is going to be very timeconsuming! Contributing to the problem is that I don't want to spend more that half a day on a single patch - I can't aford to lose time on writing patches that may not get committed. Is it possible to give fine grained svn access, I.e. just to the property files that contain the field descriptions?
Promo items
The OFBiz promo code processes product quantities as singletons. If a large quantity of an item is added to the cart (ie. 2,000) and there is a promo for that product then the result is both a large quantity of promo adjustments as well as a long processing time for the cart. For some industries large order quantities are perfectly reasonable but the current OFBiz design will fail. Does anyone have any perspective on this issue? One possible solution would be to remove the part of the promo design that reduces promo items to singletons. I realize that introduces other challenges but they seem to be deterministic. The singleton processing approach seems like an effort to keep the implementation simple. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: [VOTE] [BRANCH] Creation of the Release Branch release10.04
+1 - BJ Freeman wrote: Data expands to fill the space available for storage. A modern version is that no amount of computer automation will reduce the size of a bureaucracy -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
Re: OFBiz site as an application
Jacques Le Roux wrote: Should we not be realistic and for marketing purpose simply have the home page translated (and possibly shown accordingly to language used)? It it really a big deal for our users? +1 -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: What about moving the images to runtime folder?
I've sometimes thought that it would be nice if all the ofbiz components ran under some distinct top level path like /ofbiz. Path names like /images and /content can commonly be in use for some existing site. That would be a major change and makes the URLs even less user friendly so I have mixed feelings about the idea. In a perfect world, all the image URLs would be dynamic and you could move the images directory anywhere you want and have it just work. - Jacopo Cappellato wrote: All the images and content that are loaded (or loadable) at runtime should in my opinion be stored somewhere under the runtime folder by default (runtime/content ?) instead of framework/images This would also affect the demo images we are bundling with the system. Ideally the framework, but also the applications, could be a read only folder (after it is built, of course). -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
Re: What about renaming run-install to run-install-demo?
Jacopo Cappellato wrote: This is just *your* opinion and I respect it (even if comparing this to altering an api is ridiculous)... but please quit with the teacher/guru mode... Why is it ridiculous to think of shell script parameters as an API? You would surely be surprised if ls became rm one day, as an extreme but valid example. I think we can safely regard shell scripts as a class of program. Regarding run-install, we've set an expectation that run-install will give you a demo system and that could throw people off. Changing it doesn't seem hazardous but I'm not clear that it adds value. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: svn commit: r931594 - /ofbiz/trunk/applications/product/src/org/ofbiz/shipment/shipment/ShipmentServices.java
I'm fairly sure this fix is correct. We need to look at what the demo store is doing. Matching with an OR doesn't make sense to me. If you've specified an exact productStoreShipMethId, why should you receive anything other than the corresponding entity? - Scott Gray wrote: This commit broke the demo system, no cost estimates are returned during checkout any more.
