Re: jquey
Good morning chaps Calling selenium from the build XML is a great point. I tried that a few month ago in another project once selenium is set up right it's really helpful So in my opinion we should def think of it. Cheers Sascha Am 03.12.2010 um 07:42 schrieb Adam Heath doo...@brainfood.com: BJ Freeman wrote: Chuckle that is what I thought, and I dread more workload to just keep up. at this point I think you and I are the only ones that have invested in Selenium The solution there is to stop maintaining it outside of the normal development pipeline. Get it into trunk, make running selenium tests automatic, with a simple call in build.xml.
Re: GenericValue.getRelatedOne/Cache
Good point Adam.
+1
Am 03.12.2010 um 07:39 schrieb Adam Heath doo...@brainfood.com:
A while back, I started adding more variants of
GenericDelegator.findByPrimaryKey. The outcome of that was to remove
those variants, and reduce the methods.
However, while looking at unrelated code tonight, I thought we should
do the same to the lookup methods in GenericValue. For instance, I
saw this pattern:
if (booleanValue) {
nextValue = value.getRelatedOneCache(relation);
} else {
nextValue = value.getRelatedOne(relation);
}
I think it would be better to change that to getRelatedOne(relation,
boolean).
Do others agree? What about the other methods in that class?
Re: jquey
IMO, there are 2 options for releasing branch(es). * Only one which will be later the official release. The problem is then whether people want to have Dojo/Prototype or jQuery in this new release branch. * Two branches, one which which will be later the official release and one which will not be officially released. I would consider it as a fork since it would have Dojo/Prototype when the official will have later jQuery. Maybe fork is not really appropriate, but I think you get my point. We could also make 2 official releases. One with Dojo/Prototype and another with jQuery. I'm not quite sure switching from Dojo/Prototype to jQuery requires a specific release... Other opinions, ideas? Thanks Jacques Bruno Busco wrote: Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz
Re: GenericValue.getRelatedOne/Cache
Just my $0.02, but I am not a fan of the cache/no-cache paradigm in ofbiz.
Forcing the application developer to know about the cache leads to unstable
code and usually slower execution of the application (ie. being conservative
and saying cache-off, since it MAY be modified).
The cache is something that the application developer should never need to
concern themselves with. Of course, with ofbiz, this isn't the case, and it
has to do with the fact that the cache returns immutable objects.
I'd like to open up a discussion about changing/improving the implementation of
the entity/condition cache layer to improve this. The goals are:
- cache is passively managed by the framework. Application layer NEVER exposes
cache boolean or cache variant methods.
- goal to maintain a single object reference for the same pkey. (ie.
findByPrimaryKey() and and search by and returning same value point to the same
instance).
- soft reference on cache (ofbiz does this already).
- weak reference on entities marked non-cached (if it's in the jvm memory
already, why not return it).
- entity definition cache flag, as it is now. (controls hard/soft vs weak)
- respect transaction boundaries (current cache doesn't... try insert entity,
find it, rollback entity remains in cache).
- objects fetched from delegator are always mutable. (use a copy on write
semantic for cache).
- distributed cache semantics (already in ofbiz)
- nested views on views and proper cache behavior
Now, I am not just trying to create a make work project here. We have already
implemented all of these changes in our application's use of ofbiz. I'd be
prepared to package this up and contribute it back to the community. Please
advise.
Marc Morin
Emforium Group Inc.
ALL-IN Software
519-772-6824 ext 201
mmo...@emforium.com
- Original Message -
A while back, I started adding more variants of
GenericDelegator.findByPrimaryKey. The outcome of that was to remove
those variants, and reduce the methods.
However, while looking at unrelated code tonight, I thought we should
do the same to the lookup methods in GenericValue. For instance, I
saw this pattern:
if (booleanValue) {
nextValue = value.getRelatedOneCache(relation);
} else {
nextValue = value.getRelatedOne(relation);
}
I think it would be better to change that to getRelatedOne(relation,
boolean).
Do others agree? What about the other methods in that class?
Materialized views
We make extensive use of view entities in our ofbiz application. We have noticed that when there is a large dataset and under some complex views, the query performance was not the best (not a index issue, just complex joins, etc...). With some commercial databases like Oracle, etc... we would have used materialized view semantics available for these dbms, but we are using PostgreSQL. So, we have extended the entity layer in Ofbiz to perform the materialization. This is pretty slick as all you need to do is the following: view-entity name=myView materialize=true.../view-entity and the system will do the following: - create a backing entity called myView that has the same fields as the view - backing entity has all the indexes inherited from the component entities - relations (fk,...) inherited from the component entities. - perform all the ECA actions automatically on all entities used in the view (direct members and nested members if case of view on views). (This is an eager update strategy only). So, the application doesn't change, it still accesses myView, but now, it's result is returned from the backing entity instead of the complex SQL statement. We're pretty excited about this feature!!! Really pushes Ofbiz framework to next level and allows materialized views to be more broadly used on dbms that don't naturally support it. We are prepared to contribute this feature back to the community if desired. A note of caution about it though we have added a visitor pattern to the model entities and this feature makes use of it. It would need to come with it. Please advise. Marc Morin Emforium Group Inc. ALL-IN Software 519-772-6824 ext 201 mmo...@emforium.com
Re: jquey
I may be missing something, I don't see how to build a scenario of say doing a orderentry, can be built the say you suggest. in this scenario, it follows as if a user was inputting data and looking for results at the UI level. In simpliest, how would you redifine a element position? = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Adam Heath sent the following on 12/2/2010 10:42 PM: BJ Freeman wrote: Chuckle that is what I thought, and I dread more workload to just keep up. at this point I think you and I are the only ones that have invested in Selenium The solution there is to stop maintaining it outside of the normal development pipeline. Get it into trunk, make running selenium tests automatic, with a simple call in build.xml.
Re:Calling selenium from the build XML was jquey
what what level were you working on? I am working on scenarios for a user, like orderentry, adding products, placing order through Ecommerce. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Sascha Rodekamp sent the following on 12/3/2010 12:11 AM: Good morning chaps Calling selenium from the build XML is a great point. I tried that a few month ago in another project once selenium is set up right it's really helpful So in my opinion we should def think of it. Cheers Sascha Am 03.12.2010 um 07:42 schrieb Adam Heathdoo...@brainfood.com: BJ Freeman wrote: Chuckle that is what I thought, and I dread more workload to just keep up. at this point I think you and I are the only ones that have invested in Selenium The solution there is to stop maintaining it outside of the normal development pipeline. Get it into trunk, make running selenium tests automatic, with a simple call in build.xml.
Re: Materialized views
the Idea is good. Consideration though should be at a layer where all DB used by ofbiz can implements something similar. mysql and Postgresql are two main ones used. ms sql is also used. this is the reason, for instance that all indexes are limited to 30 since one of the db, that is its maximum index length. you will find in the Data layer that ofbiz creates temporary procedure or Functions calls to those DB that support that. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Marc Morin sent the following on 12/3/2010 6:26 AM: We make extensive use of view entities in our ofbiz application. We have noticed that when there is a large dataset and under some complex views, the query performance was not the best (not a index issue, just complex joins, etc...). With some commercial databases like Oracle, etc... we would have used materialized view semantics available for these dbms, but we are using PostgreSQL. So, we have extended the entity layer in Ofbiz to perform the materialization. This is pretty slick as all you need to do is the following: view-entity name=myView materialize=true.../view-entity and the system will do the following: - create a backing entity called myView that has the same fields as the view - backing entity has all the indexes inherited from the component entities - relations (fk,...) inherited from the component entities. - perform all the ECA actions automatically on all entities used in the view (direct members and nested members if case of view on views). (This is an eager update strategy only). So, the application doesn't change, it still accesses myView, but now, it's result is returned from the backing entity instead of the complex SQL statement. We're pretty excited about this feature!!! Really pushes Ofbiz framework to next level and allows materialized views to be more broadly used on dbms that don't naturally support it. We are prepared to contribute this feature back to the community if desired. A note of caution about it though we have added a visitor pattern to the model entities and this feature makes use of it. It would need to come with it. Please advise. Marc Morin Emforium Group Inc. ALL-IN Software 519-772-6824 ext 201 mmo...@emforium.com
Re: jquey
Hi Jacques et al, there are no real options, IMHO, jQuery is the way to go. jQuery, like it or not, is now a somewhat established 'standard', allowing corporations to hire consultants and coders for. Additionally, the existing Dojo/Prototype/Scriptalicious codebase is a _mess_ and a lot of work to clean up. Sascha did very good work, also the backend seems much faster with jQuery. I think that a good fact/opinion collection already has happened on the mailing list, so that a decision can be made. Please prevent whatever happened that prohibited not actually releasing 10.04 until today. I suggest that, based on the input so far, the three top committers come to a unanimous conclusion and decide where to go and all follow in line. I understand that a lot of people have a stake in OfBiz, but for the sake of advancement of the project I strongly believe that a clear and quick decision is necessary, even when it breaks functionality. The outcome will outweigh the momentary pain. Greetings have a nice weekend, - Karl On 03.12.2010, at 11:47, Jacques Le Roux wrote: IMO, there are 2 options for releasing branch(es). * Only one which will be later the official release. The problem is then whether people want to have Dojo/Prototype or jQuery in this new release branch. * Two branches, one which which will be later the official release and one which will not be officially released. I would consider it as a fork since it would have Dojo/Prototype when the official will have later jQuery. Maybe fork is not really appropriate, but I think you get my point. We could also make 2 official releases. One with Dojo/Prototype and another with jQuery. I'm not quite sure switching from Dojo/Prototype to jQuery requires a specific release... Other opinions, ideas? Thanks Jacques Bruno Busco wrote: Why you think that making a new release branch would create a fork? It will be managed as we manage R10.04 and R9.04 right now. Only bug fixes will be backported. -Bruno 2010/12/2 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: What about creating a tag or branch before the merge so that users who have custom projects or applications based on the trunk have a reference point in the event that they want to freeze their applications at a particular revision? Yes, that's what I have proposed. With another option: to have a branch. But I think the later is more a fork and I prefer the 1st. Oh and +1 on merging in JQuery. I am all for consolidating/simplifying our Javascript libraries. No reason to have 3 libraries that all essentially do the same thing. In the end, Javascript is Javascript. My heart says we should have chosen Prototype as that one (as anyone who knows me would agree, I'm a big Prototype JS evangelist). But, my head says that JQuery is the right choice for the long-term growth and success of the project, as it has definitely become the drug of choice for a majority of developers and has much more wide-spread community involvement as far as development of plugins is concerned. I think we now all agree on that Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Dec 2, 2010, at 11:18 AM, Jacques Le Roux wrote: I'm sorry for Bruno, but it seems everybody is looking forward for this merging. So hopefully I will do it soon. If you are interested you can already check https://issues.apache.org/jira/browse/OFBIZ-3814 Jacques Michael Xu (xudong) wrote: +1 Yeah, I would love such a great Xmas present :-) You're welcome +1 Would be a great Xmas present to merge all the stuff into the trunk :-) Am 02.12.2010 um 10:59 schrieb Erwan de FERRIERES erwan.de-ferrie...@nereide.fr: Le 02/12/2010 10:35, Jacques Le Roux a écrit : Looks like, apart Bruno, we are all on the same page so far Other opinions, ideas? Thanks Jacques The sooner the better ! Thanks for all your work, Jacques and Sascha -- Erwan de FERRIERES www.nereide.biz _ Lusini GmbH Karl Pitrich, Chief Technology Officer Adams-Lehmann-Straße 109, 80797 München Telefon +49 89 416170 113 Telefax +49 89 416170 190 E-Mail karl.pitr...@lusini.com Sitz der Gesellschaft: München, HRB 188366 Amtsgericht München, Geschäftsführer: Markus Bohl USt IdNr. DE 270565360, Steuernr. 152/131/90056 _ smime.p7s Description: S/MIME cryptographic signature
Re: Materialized views
The implementation of materialized views will work with any SQL database server. MySql, postgres, derby, oracle, etc. It is implemented using 100% ofbiz application layer constructs, entity model, and entity-eca's. Marc Morin Emforium Group Inc. ALL-IN Software 519-772-6824 ext 201 mmo...@emforium.com - Original Message - the Idea is good. Consideration though should be at a layer where all DB used by ofbiz can implements something similar. mysql and Postgresql are two main ones used. ms sql is also used. this is the reason, for instance that all indexes are limited to 30 since one of the db, that is its maximum index length. you will find in the Data layer that ofbiz creates temporary procedure or Functions calls to those DB that support that. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Marc Morin sent the following on 12/3/2010 6:26 AM: We make extensive use of view entities in our ofbiz application. We have noticed that when there is a large dataset and under some complex views, the query performance was not the best (not a index issue, just complex joins, etc...). With some commercial databases like Oracle, etc... we would have used materialized view semantics available for these dbms, but we are using PostgreSQL. So, we have extended the entity layer in Ofbiz to perform the materialization. This is pretty slick as all you need to do is the following: view-entity name=myView materialize=true.../view-entity and the system will do the following: - create a backing entity called myView that has the same fields as the view - backing entity has all the indexes inherited from the component entities - relations (fk,...) inherited from the component entities. - perform all the ECA actions automatically on all entities used in the view (direct members and nested members if case of view on views). (This is an eager update strategy only). So, the application doesn't change, it still accesses myView, but now, it's result is returned from the backing entity instead of the complex SQL statement. We're pretty excited about this feature!!! Really pushes Ofbiz framework to next level and allows materialized views to be more broadly used on dbms that don't naturally support it. We are prepared to contribute this feature back to the community if desired. A note of caution about it though we have added a visitor pattern to the model entities and this feature makes use of it. It would need to come with it. Please advise. Marc Morin Emforium Group Inc. ALL-IN Software 519-772-6824 ext 201 mmo...@emforium.com
Re: jquey
ofbiz is to me is versatility with letting different implementation work side by side. the core is that the entities when modified will display at UI level with no other changes to code. If you add a field at entity level that field will display at the UI level with no more work. So as long as any effort keeps that philosophy then I have no problem. and as long as I can continued to work on my production servers without major changes, then I am ok with it. For those that want to change this, I suggest a different effort so they can resolve their requirement but not effect the basic philosophy of ofbiz design. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Karl Pitrich sent the following on 12/3/2010 7:49 AM: I understand that a lot of people have a stake in OfBiz, but for the sake of advancement of the project I strongly believe that a clear and quick decision is necessary, even when it breaks functionality.
Re: GenericValue.getRelatedOne/Cache
+1
-Adrian
On 12/2/2010 10:39 PM, Adam Heath wrote:
A while back, I started adding more variants of
GenericDelegator.findByPrimaryKey. The outcome of that was to remove
those variants, and reduce the methods.
However, while looking at unrelated code tonight, I thought we should
do the same to the lookup methods in GenericValue. For instance, I
saw this pattern:
if (booleanValue) {
nextValue = value.getRelatedOneCache(relation);
} else {
nextValue = value.getRelatedOne(relation);
}
I think it would be better to change that to getRelatedOne(relation,
boolean).
Do others agree? What about the other methods in that class?
Re: Materialized views
submit a Jira so it can be evaluated. https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Marc Morin sent the following on 12/3/2010 8:18 AM: The implementation of materialized views will work with any SQL database server. MySql, postgres, derby, oracle, etc. It is implemented using 100% ofbiz application layer constructs, entity model, and entity-eca's. Marc Morin Emforium Group Inc. ALL-IN Software 519-772-6824 ext 201 mmo...@emforium.com - Original Message - the Idea is good. Consideration though should be at a layer where all DB used by ofbiz can implements something similar. mysql and Postgresql are two main ones used. ms sql is also used. this is the reason, for instance that all indexes are limited to 30 since one of the db, that is its maximum index length. you will find in the Data layer that ofbiz creates temporary procedure or Functions calls to those DB that support that. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.comhttp://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Marc Morin sent the following on 12/3/2010 6:26 AM: We make extensive use of view entities in our ofbiz application. We have noticed that when there is a large dataset and under some complex views, the query performance was not the best (not a index issue, just complex joins, etc...). With some commercial databases like Oracle, etc... we would have used materialized view semantics available for these dbms, but we are using PostgreSQL. So, we have extended the entity layer in Ofbiz to perform the materialization. This is pretty slick as all you need to do is the following: view-entity name=myView materialize=true.../view-entity and the system will do the following: - create a backing entity called myView that has the same fields as the view - backing entity has all the indexes inherited from the component entities - relations (fk,...) inherited from the component entities. - perform all the ECA actions automatically on all entities used in the view (direct members and nested members if case of view on views). (This is an eager update strategy only). So, the application doesn't change, it still accesses myView, but now, it's result is returned from the backing entity instead of the complex SQL statement. We're pretty excited about this feature!!! Really pushes Ofbiz framework to next level and allows materialized views to be more broadly used on dbms that don't naturally support it. We are prepared to contribute this feature back to the community if desired. A note of caution about it though we have added a visitor pattern to the model entities and this feature makes use of it. It would need to come with it. Please advise. Marc Morin Emforium Group Inc. ALL-IN Software 519-772-6824 ext 201 mmo...@emforium.com
[jira] Created: (OFBIZ-4041) Materialized views
Materialized views -- Key: OFBIZ-4041 URL: https://issues.apache.org/jira/browse/OFBIZ-4041 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: Release Branch 10.04 Reporter: Marc Morin We make extensive use of view entities in our ofbiz application. We have noticed that when there is a large dataset and under some complex views, the query performance was not the best (not a index issue, just complex joins, etc...). With some commercial databases like Oracle, etc... we would have used materialized view semantics available for these dbms, but we are using PostgreSQL. So, we have extended the entity layer in Ofbiz to perform the materialization. This is pretty slick as all you need to do is the following: view-entity name=myView materialize=true.../view-entity and the system will do the following: - create a backing entity called myView that has the same fields as the view - backing entity has all the indexes inherited from the component entities - relations (fk,...) inherited from the component entities. - perform all the ECA actions automatically on all entities used in the view (direct members and nested members if case of view on views). (This is an eager update strategy only). So, the application doesn't change, it still accesses myView, but now, it's result is returned from the backing entity instead of the complex SQL statement. We're pretty excited about this feature!!! Really pushes Ofbiz framework to next level and allows materialized views to be more broadly used on dbms that don't naturally support it. We are prepared to contribute this feature back to the community if desired. A note of caution about it though we have added a visitor pattern to the model entities and this feature makes use of it. It would need to come with it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4041) Materialized views
[ https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966615#action_12966615 ] Adam Heath commented on OFBIZ-4041: --- Is there a patch for this? Materialized views -- Key: OFBIZ-4041 URL: https://issues.apache.org/jira/browse/OFBIZ-4041 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: Release Branch 10.04 Reporter: Marc Morin We make extensive use of view entities in our ofbiz application. We have noticed that when there is a large dataset and under some complex views, the query performance was not the best (not a index issue, just complex joins, etc...). With some commercial databases like Oracle, etc... we would have used materialized view semantics available for these dbms, but we are using PostgreSQL. So, we have extended the entity layer in Ofbiz to perform the materialization. This is pretty slick as all you need to do is the following: view-entity name=myView materialize=true.../view-entity and the system will do the following: - create a backing entity called myView that has the same fields as the view - backing entity has all the indexes inherited from the component entities - relations (fk,...) inherited from the component entities. - perform all the ECA actions automatically on all entities used in the view (direct members and nested members if case of view on views). (This is an eager update strategy only). So, the application doesn't change, it still accesses myView, but now, it's result is returned from the backing entity instead of the complex SQL statement. We're pretty excited about this feature!!! Really pushes Ofbiz framework to next level and allows materialized views to be more broadly used on dbms that don't naturally support it. We are prepared to contribute this feature back to the community if desired. A note of caution about it though we have added a visitor pattern to the model entities and this feature makes use of it. It would need to come with it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New Apache CMS
On 12/03/2010 12:45 PM, Jacques Le Roux wrote: Hi committers, I think every OFBiz committer should read this http://www.apache.org/dev/cms.html Note: http://www.apache.org/dev/cms.html#confluence-phaseout Already did, months ago, which is what caused me to clone the confluence web design. My implementation deals with most of the problems outlined there.
Re: jquey
Good evening, BJ i'm on you're site. During the migration i tried to keep the old behavior. So if you're using standard components from the UI you're instances shouldn't be effected. And let me say that a few (UI) features, after the migration, are more stable and faster than the old once (i.e. the lookups). Another side point to merge in the next days is, that i have this month free time to fix bugs (which maybe occurs :-)) 2010/12/3 BJ Freeman bjf...@free-man.net ofbiz is to me is versatility with letting different implementation work side by side. the core is that the entities when modified will display at UI level with no other changes to code. If you add a field at entity level that field will display at the UI level with no more work. So as long as any effort keeps that philosophy then I have no problem. and as long as I can continued to work on my production servers without major changes, then I am ok with it. For those that want to change this, I suggest a different effort so they can resolve their requirement but not effect the basic philosophy of ofbiz design. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Karl Pitrich sent the following on 12/3/2010 7:49 AM: I understand that a lot of people have a stake in OfBiz, but for the sake of advancement of the project I strongly believe that a clear and quick decision is necessary, even when it breaks functionality. -- Sascha Rodekamp Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de
Re: New Apache CMS
Ah interesting Jacques. Thanks for the info. Cheers 2010/12/3 Adam Heath doo...@brainfood.com On 12/03/2010 12:45 PM, Jacques Le Roux wrote: Hi committers, I think every OFBiz committer should read this http://www.apache.org/dev/cms.html Note: http://www.apache.org/dev/cms.html#confluence-phaseout Already did, months ago, which is what caused me to clone the confluence web design. My implementation deals with most of the problems outlined there. -- Sascha Rodekamp Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de
Re: jquey
so you have some selenium tests that work on the same pages between trunk and jquery. good to hear. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Sascha Rodekamp sent the following on 12/3/2010 11:32 AM: Good evening, BJ i'm on you're site. During the migration i tried to keep the old behavior. So if you're using standard components from the UI you're instances shouldn't be effected. And let me say that a few (UI) features, after the migration, are more stable and faster than the old once (i.e. the lookups). Another side point to merge in the next days is, that i have this month free time to fix bugs (which maybe occurs :-)) 2010/12/3 BJ Freemanbjf...@free-man.net ofbiz is to me is versatility with letting different implementation work side by side. the core is that the entities when modified will display at UI level with no other changes to code. If you add a field at entity level that field will display at the UI level with no more work. So as long as any effort keeps that philosophy then I have no problem. and as long as I can continued to work on my production servers without major changes, then I am ok with it. For those that want to change this, I suggest a different effort so they can resolve their requirement but not effect the basic philosophy of ofbiz design. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.comhttp://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Karl Pitrich sent the following on 12/3/2010 7:49 AM: I understand that a lot of people have a stake in OfBiz, but for the sake of advancement of the project I strongly believe that a clear and quick decision is necessary, even when it breaks functionality.
[jira] Commented: (OFBIZ-3843) Localized date format for end user
[ https://issues.apache.org/jira/browse/OFBIZ-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1296#action_1296 ] Jacques Le Roux commented on OFBIZ-3843: Hi Nicolas, DId you have a look at Sascha's proposition: OFBIZ-4014 ? Thanks Localized date format for end user -- Key: OFBIZ-3843 URL: https://issues.apache.org/jira/browse/OFBIZ-3843 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Nicolas Malin Priority: Minor Attachments: OFBIZ-3843.patch, OFBIZ-3843.patch, With the patch.jpg, Without patch (in trunk demo).jpg, Wrong From Date.jpg Many French end users don't want to use this date format : -mm-dd. To make a better user friendly OFBiz interface, I've added the possibility to configure in general.properties a localized date format. OFBiz use localized format (as dd/mm/) for all interactions with users but keep universal format for its framework. It's then possible to set date with unniversal or localized format. What's working : * Dates in screen engine : display, date-find, date-time * performFind * Service call Know problem : * I don't find how to configure js calendar to support this functionality It's possible that my solution isn't the best one to do that. But I'm open to all comment -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4041) Materialized views
[ https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966673#action_12966673 ] Marc Morin commented on OFBIZ-4041: --- Not yet, I would need to pull it out of our OFbiz source tree... which is about a year old and co-mingled with a lot of other framework goodies... I am prepared to do the work though if the community wants the feature. Marc Morin Emforium Group Inc. ALL-IN Software 519-772-6824 ext 201 mmo...@emforium.com - Original Message - Materialized views -- Key: OFBIZ-4041 URL: https://issues.apache.org/jira/browse/OFBIZ-4041 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: Release Branch 10.04 Reporter: Marc Morin We make extensive use of view entities in our ofbiz application. We have noticed that when there is a large dataset and under some complex views, the query performance was not the best (not a index issue, just complex joins, etc...). With some commercial databases like Oracle, etc... we would have used materialized view semantics available for these dbms, but we are using PostgreSQL. So, we have extended the entity layer in Ofbiz to perform the materialization. This is pretty slick as all you need to do is the following: view-entity name=myView materialize=true.../view-entity and the system will do the following: - create a backing entity called myView that has the same fields as the view - backing entity has all the indexes inherited from the component entities - relations (fk,...) inherited from the component entities. - perform all the ECA actions automatically on all entities used in the view (direct members and nested members if case of view on views). (This is an eager update strategy only). So, the application doesn't change, it still accesses myView, but now, it's result is returned from the backing entity instead of the complex SQL statement. We're pretty excited about this feature!!! Really pushes Ofbiz framework to next level and allows materialized views to be more broadly used on dbms that don't naturally support it. We are prepared to contribute this feature back to the community if desired. A note of caution about it though we have added a visitor pattern to the model entities and this feature makes use of it. It would need to come with it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-4008) displaying promoText in finalizeOrder is wrongly done
[ https://issues.apache.org/jira/browse/OFBIZ-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4008. -- Resolution: Fixed Assignee: Jacques Le Roux Thanks for report Erwan, Fixed in trunk at r1042009, R10.04 at r1042013, R9.04 at r1042015. displaying promoText in finalizeOrder is wrongly done - Key: OFBIZ-4008 URL: https://issues.apache.org/jira/browse/OFBIZ-4008 Project: OFBiz Issue Type: Bug Components: order Affects Versions: SVN trunk Reporter: Erwan de FERRIERES Assignee: Jacques Le Roux Priority: Critical Fix For: SVN trunk Attachments: OFBIZ-4008.png Steps to reproduce : Create an order with 6 GZ-1000 gizmos, and finalize the order. When coming on reviewing order, the order items list, with adjustements is displayed, and the promoText for the GZ-1006-4 - Open Gizmo (MIT) is shown, but the link is in full text, and not interpreted as a link (see screenshot). Another error due to this can also be found when calling createInvoiceItem, as the promoText is a CDATA field, and is tried in this service to be changed as a text field (invoiceItem.description), which causes an error as it is not allowing '' and '' signs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4041) Materialized views
[ https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966681#action_12966681 ] Jacques Le Roux commented on OFBIZ-4041: I'm interested... Materialized views -- Key: OFBIZ-4041 URL: https://issues.apache.org/jira/browse/OFBIZ-4041 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: Release Branch 10.04 Reporter: Marc Morin We make extensive use of view entities in our ofbiz application. We have noticed that when there is a large dataset and under some complex views, the query performance was not the best (not a index issue, just complex joins, etc...). With some commercial databases like Oracle, etc... we would have used materialized view semantics available for these dbms, but we are using PostgreSQL. So, we have extended the entity layer in Ofbiz to perform the materialization. This is pretty slick as all you need to do is the following: view-entity name=myView materialize=true.../view-entity and the system will do the following: - create a backing entity called myView that has the same fields as the view - backing entity has all the indexes inherited from the component entities - relations (fk,...) inherited from the component entities. - perform all the ECA actions automatically on all entities used in the view (direct members and nested members if case of view on views). (This is an eager update strategy only). So, the application doesn't change, it still accesses myView, but now, it's result is returned from the backing entity instead of the complex SQL statement. We're pretty excited about this feature!!! Really pushes Ofbiz framework to next level and allows materialized views to be more broadly used on dbms that don't naturally support it. We are prepared to contribute this feature back to the community if desired. A note of caution about it though we have added a visitor pattern to the model entities and this feature makes use of it. It would need to come with it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (OFBIZ-4041) Materialized views
Ok, I will try to spend some time this weekend in order to pull a patch together for this. - Original Message - [ https://issues.apache.org/jira/browse/OFBIZ-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966681#action_12966681 ] Jacques Le Roux commented on OFBIZ-4041: I'm interested... Materialized views -- Key: OFBIZ-4041 URL: https://issues.apache.org/jira/browse/OFBIZ-4041 Project: OFBiz Issue Type: New Feature Components: framework Affects Versions: Release Branch 10.04 Reporter: Marc Morin We make extensive use of view entities in our ofbiz application. We have noticed that when there is a large dataset and under some complex views, the query performance was not the best (not a index issue, just complex joins, etc...). With some commercial databases like Oracle, etc... we would have used materialized view semantics available for these dbms, but we are using PostgreSQL. So, we have extended the entity layer in Ofbiz to perform the materialization. This is pretty slick as all you need to do is the following: view-entity name=myView materialize=true.../view-entity and the system will do the following: - create a backing entity called myView that has the same fields as the view - backing entity has all the indexes inherited from the component entities - relations (fk,...) inherited from the component entities. - perform all the ECA actions automatically on all entities used in the view (direct members and nested members if case of view on views). (This is an eager update strategy only). So, the application doesn't change, it still accesses myView, but now, it's result is returned from the backing entity instead of the complex SQL statement. We're pretty excited about this feature!!! Really pushes Ofbiz framework to next level and allows materialized views to be more broadly used on dbms that don't naturally support it. We are prepared to contribute this feature back to the community if desired. A note of caution about it though we have added a visitor pattern to the model entities and this feature makes use of it. It would need to come with it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-4024) Improve handling and display of additional product images
[ https://issues.apache.org/jira/browse/OFBIZ-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4024. -- Resolution: Fixed Fix Version/s: SVN trunk Assignee: Jacques Le Roux Thanks Anne, Your patch is in trunk at r1042024, well done! Improve handling and display of additional product images - Key: OFBIZ-4024 URL: https://issues.apache.org/jira/browse/OFBIZ-4024 Project: OFBiz Issue Type: Improvement Components: product, specialpurpose/ecommerce Affects Versions: SVN trunk Environment: Rev 1035845 Reporter: Anne Jessel Assignee: Jacques Le Roux Priority: Minor Fix For: SVN trunk Attachments: OFBIZ-4024_additional-images-enhancements.patch This patch adds several closely-related features, intended to improve the display of products and their images in the ecommerce webapp. When additional images for a product are uploaded via the Catalog, the scaled versions that were already being created in service addAdditionalViewForProduct are now recorded as ProductContent. This makes them easily available for use elsewhere. New ProductContentType values were added to identify these content types. The obviously consistent string to use for these was too long, and so I had to choose something less consistent, but shorter and hopefully still clear. I used XTRA instead of ADDITIONAL. The sizes to which additional images are rescaled has been changed, so they better fit in the ecommerce display. Relevant sizes in productdetail.ftl have been updated to match these sizes. The ecommerce product display now uses the scaled additional images if available, rather than relying on the web browser to scale the images. When displaying a single product in ecommerce, the main image is larger than the additional images. Hovering over an additional image displays a larger version in place of the main image. Clicking on an additional image displays a popup with a detailed version of the image. To use the new features, one or more large images (suggest at least 600x600) should be attached as additional images to a product, using the form on the bottom of the content tab for a product in Catalog. Viewing the product in ecommerce should then exhibit the above behaviour. I have tried to maintain backwards compatibility, so that products with the old-style use of additional images will continue to display as they did previously. This means some of the code is not as streamlined as it might be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-4038) Rounding error in prorating returned adjustments
[ https://issues.apache.org/jira/browse/OFBIZ-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4038. -- Resolution: Fixed Fix Version/s: SVN trunk Release Branch 10.04 Release Branch 09.04 Assignee: Jacques Le Roux Thanks Jeremy, Your suggested change is trunk at r1042034 ,R10.04 at r1042036, R9.04 at r1042037 It may seem obvious, but I would just have preferred that you would not have omited the setScale part. :p Rounding error in prorating returned adjustments Key: OFBIZ-4038 URL: https://issues.apache.org/jira/browse/OFBIZ-4038 Project: OFBiz Issue Type: Bug Affects Versions: Release Branch 09.04, Release 09.04, Release Branch 10.04 Reporter: Wickersheimer Jeremy Assignee: Jacques Le Roux Priority: Minor Fix For: Release Branch 09.04, Release Branch 10.04, SVN trunk The error is in applications/order/src/org/ofbiz/order/order/OrderReturnServices.java the getAdjustmentAmount method is prorating using this code: newAmount = returnTotal.divide(originalTotal, decimals, rounding).multiply(amount).setScale(decimals, rounding); it should be: newAmount = returnTotal.multiply(amount).divide(originalTotal, decimals, rounding); else by dividing first what should be for example 1/3 of the adjustment ends up being 0.33 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4037) Moving the user SignUp feature from MyPortal to the Framework
[ https://issues.apache.org/jira/browse/OFBIZ-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966712#action_12966712 ] Bruno Busco commented on OFBIZ-4037: Hi, I would like to commit this patch. Does somebody see any issue? I would set the OOTB values for the configuration parameters so that the SignUp feature is enabled with Captcha code check. Are you OK with this setting or do you think that by default the feature should be disabled? Right now we have that it is disabled on all application but MyPortal. After the patch the feature will be enabled/disabled for all applications. Moving the user SignUp feature from MyPortal to the Framework - Key: OFBIZ-4037 URL: https://issues.apache.org/jira/browse/OFBIZ-4037 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Bruno Busco Attachments: ofbiz_signup.patch Hi Devs! In the attached patch I have reworked the feature that allows a new user to SignUp for an account. This feature is actually only available when logging in at the MyPortal application. Well, IMO it should be centrally available so that the login screen is exactly the same regardless of the application. The Captcha feature is already implemented (captcha.java) partially in the framework and so this patch should be seen as a clean up also. I added full internationalization of all labels and created some labels in the CommonUiLabels.xml file. I would like some review so that I could then commit if nobody finds something wrong. By the way, there is for sure some improvement that could be done at a later stage: - Eliminate the labels that have been created in the CommonUiLabels from Party and MyPortal - Add an encription of the Captcha code so that it will not be easily broken by robots. Thank you for any comment you could provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-4034) Added Labels for Option-fields in FindProductPromoCode.ftl
[ https://issues.apache.org/jira/browse/OFBIZ-4034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-4034. -- Resolution: Fixed Fix Version/s: Release Branch 10.04 Release Branch 09.04 Assignee: Jacques Le Roux Thanks Mirko, Your patch is in trunk at r1042038. I think we should also backport such changes so I did it for R10.04 at r1042042 and R9.04 at r1042044. It's improvement at the dev level. But for me a bug in 1st place as the i18n is missing. So from an user POV it's a bug... Added Labels for Option-fields in FindProductPromoCode.ftl -- Key: OFBIZ-4034 URL: https://issues.apache.org/jira/browse/OFBIZ-4034 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: SVN trunk Reporter: Mirko Vogelsmeier Assignee: Jacques Le Roux Priority: Minor Fix For: Release Branch 09.04, Release Branch 10.04, SVN trunk Attachments: FindProductPromoCode.ftl.patch Hi there, i added some Labels for the option fields in FindProductPromoCode.ftl. Greetings, Mirko -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
How to automatically set columns in a list form from a map?
Hi, I am looking for a way to automatically populate a list form from a map. Basically I would need something like a auto-fields-list tag that would work in a similar way to auto-fields-entity and auto-fields-service but taking fields information from the form list and not from a service or an entity. Does this make sense? Thank you, Bruno
[jira] Commented: (OFBIZ-4021) Adding columns filtering fields in form widget
[ https://issues.apache.org/jira/browse/OFBIZ-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966723#action_12966723 ] Bruno Busco commented on OFBIZ-4021: Hi, is anybody interested in this feature? Thank you, Bruno Adding columns filtering fields in form widget -- Key: OFBIZ-4021 URL: https://issues.apache.org/jira/browse/OFBIZ-4021 Project: OFBiz Issue Type: New Feature Components: framework Reporter: Bruno Busco Priority: Minor Attachments: column_filter_disabled.JPG, column_filter_enabled.JPG, content_list.JPG, FilterForm.patch, FilterForm.patch, img_for_tomahawk.zip This patch includes an initial implementation of a list-form column filtering feature. The aim is to add the possibility to configure a list form to show, in its header, some fields that could be used to filter the rows displayed in the form. This is a feature quite standard in many systems and could be seen into OFBiz as a quick search; the standard way of searching using a complete single-type form could be seen as an advanced search. Please find attached to this JIRA two screenshots that show you how the filtering option appears on the screen. *How the user uses this feature* The part of the screen that is normally used for the pagination controls (only the upper one) has been extended so that two icons are shown on the left. The first one (a funnel) is used to show or hide the filtering fields. The second one (a magnifing glass) is used to run the search with the filter content. *How the developer uses this feature* The filtering feature can be enabled on any list-type form specifying the filter-form-name attribute. This must be the name of a form that contains the details about how the filtering fields should be rendered. When a list form with the filter-form-name option set is rendered, any column field is searched for in the filter-form. If a field with the same name is found, its field rendering options are used to render the filter field. A new field attribute filter-field has also been added. This defaults to true but if it is set to false the filter field is not rendered for this column, even if a field with the same name is present in the filter-form. This feature allows to use as filter-form an already existent form such as a regular FindXXX form. In the patch the ListExample form has been changed to use this feature. You can check it there. Unfortunately the patch does not work yet 100% but I hope that if someone finds it interesting could help me. *What is there still to do* 1) There is a FIXME in MacroFormRenderer.java file. I cannot make it work. If I enable the code that is commented there I get an error when a search is run. 2) I cannot make the filtering fields show the actual content after a search is run. They are always rendered as empty. 3) The filter row hide/show status should be saved so that it is maintained after a pagination. I submit this patch as it is becouse I cannot easily improve it further but I hope someone could help. The img_for_tamahawk.zip file includes imgs that should be added in the tomahawk images folder to make the patch work. Thank you for any help! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Adding a standars CSV export feature to list forms
Hi, I was thinking that having a CSV export feature embedded in the list form widget could be nice. I mean a feature that, simply adding something like a csv-export=true attribute in the form widget, would show a link or an icon in the top form pagination bar that would export the actual data listed in the form. Does this make sense? Any idea on how to implement this? Many thanks to everybody wants to share ideas on this. -Bruno
Re: Adding a standars CSV export feature to list forms
hi Bruno we discussed this issue at: https://issues.apache.org/jira/browse/OFBIZ-3981, which, however, relates to jquery. -- Regards, Michael Xu (xudong) On Sat, Dec 4, 2010 at 7:22 AM, Bruno Busco bruno.bu...@gmail.com wrote: Hi, I was thinking that having a CSV export feature embedded in the list form widget could be nice. I mean a feature that, simply adding something like a csv-export=true attribute in the form widget, would show a link or an icon in the top form pagination bar that would export the actual data listed in the form. Does this make sense? Any idea on how to implement this? Many thanks to everybody wants to share ideas on this. -Bruno
Re: Adding a standars CSV export feature to list forms
Hi Bruno, this is not exactly the same topic but I would like to share some of my ideas for enhancements for the macro screen widget. Currently, in order to get an html and a csv version of a screen we have to create the two screen definitions (with different decorators) and setup entries in the controller like: view-map name=InventoryItemTotals type=screen page=component://product/widget/facility/FacilityScreens.xml#InventoryItemTotals/ view-map name=InventoryItemTotalsExport type=screencsv page=component://product/widget/facility/FacilityScreens.xml#InventoryItemTotalsExport content-type=text/csv encoding=none/ The following improvements will make the rendering in different formats more dynamic: 1) in the controller, the two view-maps could be grouped into one where the content-type is dynamically retrieved from the request (then the view handler will use screen or screencsv etc based on the content type) 2) enhance the global decorator to render properly on different formats; if the decorator contains screens/forms widgets then the widget should render themselves in the proper format; if the decorator contains ftl templates, we will have to provide alternative ones like: platform-specific htmlhtml-template location=component://common/webcommon/includes/simple.ftl//html xsl-fohtml-template location=component://common/webcommon/includes/simple.fo.ftl//xsl-fo xmlhtml-template location=component://common/webcommon/includes/minimal-decorator.ftl//xml /platform-specific 3) in the search form we could add a drop down for the selection of the content-type At this point we may be able to export in different formats virtually any screen in OFBiz simply by adding a drop down box for the output format at the top of the screen (in a decorator): export to PDF, export to xml. Jacopo On Dec 4, 2010, at 12:22 AM, Bruno Busco wrote: Hi, I was thinking that having a CSV export feature embedded in the list form widget could be nice. I mean a feature that, simply adding something like a csv-export=true attribute in the form widget, would show a link or an icon in the top form pagination bar that would export the actual data listed in the form. Does this make sense? Any idea on how to implement this? Many thanks to everybody wants to share ideas on this. -Bruno
Re: Adding a standars CSV export feature to list forms
Hi Jacopo, thank you for your proposal. In my mind there was only something like your #1. This would allow to embed an export link in the form (I would like to include a standard download icon in the list form pagination bar) whose target is automatically derived from the form's target. This link could be rendered if the cvs-export=true is added to the frame attributes. #2 will for sure add more generality and would allow the export to any screen even not just a form. This would be great. #3 Yes, but I would prefer to have specific icons i the top bars (i.e. the form pagination or the screenlet title bar) The export link should perform a request with the same search parameters as the last one. Thank you very much for discussing on this. -Bruno 2010/12/4 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi Bruno, this is not exactly the same topic but I would like to share some of my ideas for enhancements for the macro screen widget. Currently, in order to get an html and a csv version of a screen we have to create the two screen definitions (with different decorators) and setup entries in the controller like: view-map name=InventoryItemTotals type=screen page=component://product/widget/facility/FacilityScreens.xml#InventoryItemTotals/ view-map name=InventoryItemTotalsExport type=screencsv page=component://product/widget/facility/FacilityScreens.xml#InventoryItemTotalsExport content-type=text/csv encoding=none/ The following improvements will make the rendering in different formats more dynamic: 1) in the controller, the two view-maps could be grouped into one where the content-type is dynamically retrieved from the request (then the view handler will use screen or screencsv etc based on the content type) 2) enhance the global decorator to render properly on different formats; if the decorator contains screens/forms widgets then the widget should render themselves in the proper format; if the decorator contains ftl templates, we will have to provide alternative ones like: platform-specific htmlhtml-template location=component://common/webcommon/includes/simple.ftl//html xsl-fohtml-template location=component://common/webcommon/includes/simple.fo.ftl//xsl-fo xmlhtml-template location=component://common/webcommon/includes/minimal-decorator.ftl//xml /platform-specific 3) in the search form we could add a drop down for the selection of the content-type At this point we may be able to export in different formats virtually any screen in OFBiz simply by adding a drop down box for the output format at the top of the screen (in a decorator): export to PDF, export to xml. Jacopo On Dec 4, 2010, at 12:22 AM, Bruno Busco wrote: Hi, I was thinking that having a CSV export feature embedded in the list form widget could be nice. I mean a feature that, simply adding something like a csv-export=true attribute in the form widget, would show a link or an icon in the top form pagination bar that would export the actual data listed in the form. Does this make sense? Any idea on how to implement this? Many thanks to everybody wants to share ideas on this. -Bruno
[jira] Commented: (OFBIZ-4037) Moving the user SignUp feature from MyPortal to the Framework
[ https://issues.apache.org/jira/browse/OFBIZ-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966793#action_12966793 ] Bruno Busco commented on OFBIZ-4037: As Hans suggests on the dev ML having the feature enabled would be better to show OOTB the feature. Thank you Hans. Moving the user SignUp feature from MyPortal to the Framework - Key: OFBIZ-4037 URL: https://issues.apache.org/jira/browse/OFBIZ-4037 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Bruno Busco Attachments: ofbiz_signup.patch Hi Devs! In the attached patch I have reworked the feature that allows a new user to SignUp for an account. This feature is actually only available when logging in at the MyPortal application. Well, IMO it should be centrally available so that the login screen is exactly the same regardless of the application. The Captcha feature is already implemented (captcha.java) partially in the framework and so this patch should be seen as a clean up also. I added full internationalization of all labels and created some labels in the CommonUiLabels.xml file. I would like some review so that I could then commit if nobody finds something wrong. By the way, there is for sure some improvement that could be done at a later stage: - Eliminate the labels that have been created in the CommonUiLabels from Party and MyPortal - Add an encription of the Captcha code so that it will not be easily broken by robots. Thank you for any comment you could provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
