Re: Renaming some ant tasks to improve consistency
+1 2012/3/26 Ashish Vijaywargiya vijaywargiya.ash...@gmail.com +1 for the proposal. -- Ashish On Mon, Mar 26, 2012 at 7:27 PM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: Hi all, I have reviewed the names of our ant tasks and I would like to propose to rename [*] some of them to make them more consistent with what they actually do. In short, I would like to: * rename some run tasks with the word start because they actually start OFBiz * rename run-install* tasks with the word load because they actually load data ** rename the task that loads demo data from run-install to a more explicit load-demo Here is the complete list of proposed changes: run -- start run-debug -- start-debug run-pos -- start-pos run-install -- load-demo run-install-* targets -- load-* (for example: run-install-seed -- load-seed etc...) What do you think? Jacopo [*] if we are worried about backward compatibility (even if this is not actually a *compatibility* issue) we could keep the old ones (to call the new ones); I personally don't think it is necessary and we could clean them to have a cleaner build.xml file for future evolution but I would not be against keeping the old ones as well if there is enough consensus.
Re: Framework refactor
Jacopo, I would go, or at least, deeply consider option: 3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be possible if Moqui release will have all the features we need (and if Moqui community will be interested in getting contribution to evolve in the direction required by OFBzi) I think that David will be more than interested in evaluating every feature needed by OFBiz. He has already started the mantle and crust projects that, on top of the Moqui framework, should be something like a reworked OFBiz. -Bruno 2012/3/2 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote: Jacopo, You would even consider forking? From Wikipedia [*]: [...] More recently, distributed revision control (DVCS) tools have popularised a less emotive use of the term fork, blurring the distinction with branch. With a DVCS such as Mercurial or Git, the normal way to contribute to a project is to first branch the repository, and later seek to have your changes integrated with the main repository. Sites such as Github, Bitbucket and Launchpad provide free DVCS hosting expressly supporting independent branches, such that the technical, social and financial barriers to forking a source code repository are massively reduced. In order of preference (descending), here are the options I see for the future of the OFBiz framework: 1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then release it separately from the Apache OFBiz ERP 2) greatly clean up and improve the existing framework (I was not sure if this could go at #1) 3) if the above will not be possible (frankly speaking, in the committers group, apart from David, none of us ever implemented with success an open source framework) we should also consider to drop the existing code and have our community focusing on the ERP part (as Hans seems to advocate); at this point Moqui would be the most natural choice; if we will ever go with this path a great exchange of information will have to happen between the two projects: for example OFBiz will probably have to ask the Moqui framework to evolve some of its features; given the current nature of the Moqui project, I doubt that the OFBiz committers will be ever invited as committers there; if Moqui will be our choice, I see two possibilities: 3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be possible if Moqui release will have all the features we need (and if Moqui community will be interested in getting contribution to evolve in the direction required by OFBzi) 3.b) if 3.a will not be possible because OFBiz will need some features that Moqui community will not consider as a good fit for Moqui, then, under the guidance and bless of David, we could work on a fork: get the code from a Moqui release, import in our repository and add to it, in a controlled way, the features we need; of course this should be always kept as close as possible to the original code; we could synch our custom code with every new Moqui release; I was not thinking about *stealing* code to Moqui and the fact that David is both the founder of OFBiz and of Moqui and he is both in the OFBiz PMC and the leader of the Moqui project will definitely facilitate this; but it will be still an ugly solution but for example when you said: My proposal is that Apache OFBiz will be in the future just the ERP system based on many opensource products like birt and also Moqui you are actually implying that the ERP applications will be able to use Birt... but this requires some sort of framework and what would you do if Moqui will not think that Birt is a good fit for them? 4) if Moqui will not be a good option we may consider other frameworks (?), but it will be difficult, or continue with what we have Jacopo [*]: http://en.wikipedia.org/wiki/Fork_(software_development)
Re: [VOTE] [RELEASE] Apache OFBiz 09.04.02
+1 2012/2/23 Pierre Smits pierre.sm...@gmail.com +1 Pierre Smits 2012/2/23 Jacques Le Roux jacques.le.r...@les7arts.com +1 Jacques From: Jacopo Cappellato jacopo.cappellato@**hotwaxmedia.com jacopo.cappell...@hotwaxmedia.com This is the vote thread to release a new (bug fix) release for the 09.04 branch. This new release, Apache OFBiz 09.04.02 (major release number: 09.04; minor release number: 02), will supersede the release Apache OFBiz 09.04.01. The release files can be downloaded from here: http://people.apache.org/~**jacopoc/dist/ http://people.apache.org/~jacopoc/dist/ and are: * apache-ofbiz-09.04.02.zip: the release package, based on the 09.04 branch at revision 1291780 (latest as of now) * KEYS: text file with keys * apache-ofbiz-09.04.02.zip.asc: the detached signature file * apache-ofbiz-09.04.02.zip.md5, apache-ofbiz-09.04.02.zip.sha: hashes Please download and test the zip file and its signatures (for instructions on testing the signatures see http://www.apache.org/info/** verification.html http://www.apache.org/info/verification.html). Vote: [ +1] release as Apache OFBiz 09.04.02 [ -1] do not release This vote will be closed in 72 hours. For more details about this process please read http://www.apache.org/** foundation/voting.html http://www.apache.org/foundation/voting.html The following text is quoted from the above url: Votes on whether a package is ready to be released use majority approval -- i.e. at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes. Releases may not be vetoed. Generally the community will cancel the release vote if anyone identifies serious problems, but in most cases the ultimate decision, lies with the individual serving as release manager. Kind Regards, Jacopo
[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=13139555#comment-13139555 ] Bruno Busco commented on OFBIZ-4021: Hi Jacques, yes, at that time I asked for a review of the POC. The idea was to improve the list form with a feature that is quite standard on other platforms. I was not sure that the way I implemented it was OK. I did not go further on this. But yes I am still interested in receiving comments. Adding columns filtering fields in form widget -- Key: OFBIZ-4021 URL: https://issues.apache.org/jira/browse/OFBIZ-4021 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Bruno Busco Priority: Minor Attachments: FilterForm.patch, FilterForm.patch, column_filter_disabled.JPG, column_filter_enabled.JPG, content_list.JPG, 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Changing the Jar files loading order
Info about that are contained in the README.txt file in the hot-deploy folder. -Bruno 2011/7/14 Scott Gray scott.g...@hotwaxmedia.com On 14/07/2011, at 8:12 AM, Adam Heath wrote: On 07/11/2011 05:50 AM, Ajay Lashkari wrote: Hi All, when we start the ofbiz, it loads framework-applications-specialpurpose and then hot-deploy. so please tell me that if there is a way to change the loading order of there relevant jar files , from where i can change it? if there is any file exist for that configuration please tell me the name of it. If you want to change the order of things that are loaded from hot-deploy, then just change the name to something that will sort earlier alphabetically. Ie: hot-deploy/foo loads *after* hot-deploy/bar. hot-deploy/00-foo would load *before* bar. Or you can just drop a component-load.xml into the hot-deploy folder and explicitly define the load order.
[jira] [Commented] (OFBIZ-4313) setUserPreference goes to main page instead last view if current form includes any lookup field
[ https://issues.apache.org/jira/browse/OFBIZ-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051659#comment-13051659 ] Bruno Busco commented on OFBIZ-4313: Could it be related to the button used to expand/collapse the header ? setUserPreference goes to main page instead last view if current form includes any lookup field - Key: OFBIZ-4313 URL: https://issues.apache.org/jira/browse/OFBIZ-4313 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: SVN trunk Reporter: Leon Priority: Minor Fix For: SVN trunk Attachments: lookup_lastViewName.patch When I open a form which include lookup field and then click the set User Preference button around the upper right corner, the page will go to main after user preference is setted. The cause is the requests initiated by lookup field does not remeber the last view name. It simply use main instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r1098406 - in /ofbiz/trunk/framework/webtools: webapp/webtools/datafile/ webapp/webtools/entity/ webapp/webtools/service/ widget/
OK Adrian, it's done.
Bruno
2011/5/1 Adrian Crum adrian.c...@sandglass-software.com
I don't like some of these changes. Removing the unnecessary screenlets was
a good idea. Removing the page title is a bad idea, and it doesn't follow
layout best practices:
https://cwiki.apache.org/OFBADMIN/user-interface-layout-best-practices.html
https://localhost:8443/webtools/control/WebtoolsLayoutDemo
-Adrian
On 5/1/2011 1:38 PM, bus...@apache.org wrote:
Author: buscob
Date: Sun May 1 20:38:38 2011
New Revision: 1098406
URL: http://svn.apache.org/viewvc?rev=1098406view=rev
Log:
No funtional changes only layout.
Screenlet title bars and H1 titles have been removed when they simply
duplicate the tab menu.
Fixed some missing tab menu highlighting.
Modified:
ofbiz/trunk/framework/webtools/webapp/webtools/datafile/viewdatafile.ftl
ofbiz/trunk/framework/webtools/webapp/webtools/entity/CheckDb.ftl
ofbiz/trunk/framework/webtools/webapp/webtools/entity/EntityExportAll.ftl
ofbiz/trunk/framework/webtools/webapp/webtools/entity/EntityImport.ftl
ofbiz/trunk/framework/webtools/webapp/webtools/entity/EntityImportDir.ftl
ofbiz/trunk/framework/webtools/webapp/webtools/entity/EntityImportReaders.ftl
ofbiz/trunk/framework/webtools/webapp/webtools/entity/EntityMaint.ftl
ofbiz/trunk/framework/webtools/webapp/webtools/entity/EntitySQLProcessor.ftl
ofbiz/trunk/framework/webtools/webapp/webtools/entity/xmldsdump.ftl
ofbiz/trunk/framework/webtools/webapp/webtools/service/availableservices.ftl
ofbiz/trunk/framework/webtools/widget/CacheScreens.xml
ofbiz/trunk/framework/webtools/widget/EntityScreens.xml
ofbiz/trunk/framework/webtools/widget/EntitySyncScreens.xml
ofbiz/trunk/framework/webtools/widget/LogScreens.xml
ofbiz/trunk/framework/webtools/widget/Menus.xml
ofbiz/trunk/framework/webtools/widget/MiscScreens.xml
ofbiz/trunk/framework/webtools/widget/ServiceScreens.xml
Modified:
ofbiz/trunk/framework/webtools/webapp/webtools/datafile/viewdatafile.ftl
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/webtools/webapp/webtools/datafile/viewdatafile.ftl?rev=1098406r1=1098405r2=1098406view=diff
==
---
ofbiz/trunk/framework/webtools/webapp/webtools/datafile/viewdatafile.ftl
(original)
+++
ofbiz/trunk/framework/webtools/webapp/webtools/datafile/viewdatafile.ftl Sun
May 1 20:38:38 2011
@@ -16,15 +16,6 @@ KIND, either express or implied. See th
specific language governing permissions and limitations
under the License.
--
-div class=screenlet
-div class=screenlet-title-bar
-ul
-li class=h3${uiLabelMap.WebtoolsDataFileMainTitle}/li
-/ul
-br class=clear/
-/div
-div class=screenlet-body
-br /
p${uiLabelMap.WebtoolsDataFileMessage1}./p
br /
#if security.hasPermission(DATAFILE_MAINT, session)
@@ -159,5 +150,3 @@ under the License.
#else
h3You do not have permission to use this page (DATAFILE_MAINT
needed)/h3
/#if
-/div
-/div
Modified:
ofbiz/trunk/framework/webtools/webapp/webtools/entity/CheckDb.ftl
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/webtools/webapp/webtools/entity/CheckDb.ftl?rev=1098406r1=1098405r2=1098406view=diff
==
--- ofbiz/trunk/framework/webtools/webapp/webtools/entity/CheckDb.ftl
(original)
+++ ofbiz/trunk/framework/webtools/webapp/webtools/entity/CheckDb.ftl Sun
May 1 20:38:38 2011
@@ -16,7 +16,6 @@ KIND, either express or implied. See th
specific language governing permissions and limitations
under the License.
--
-div
h3${uiLabelMap.WebtoolsCheckUpdateDatabase}/h3
form method=post action=${encodeURLCheckDb}
input type=hidden name=option value=checkupdatetables/
@@ -111,9 +110,8 @@ under the License.
${uiLabelMap.WebtoolsGroupName}:input type=text
name=groupName value=${groupName} size=40/
input type=submit value=${uiLabelMap.CommonUpdate}/
/form
-hr /
-/div
#if miters?has_content
+hr /
ul
#list miters as miter
li${miter}/li
Modified:
ofbiz/trunk/framework/webtools/webapp/webtools/entity/EntityExportAll.ftl
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/webtools/webapp/webtools/entity/EntityExportAll.ftl?rev=1098406r1=1098405r2=1098406view=diff
==
---
ofbiz/trunk/framework/webtools/webapp/webtools/entity/EntityExportAll.ftl
(original)
+++
ofbiz/trunk/framework/webtools/webapp/webtools/entity/EntityExportAll.ftl
Sun May 1 20:38:38 2011
@@ -17,11 +17,7 @@ specific language governing permissions
under the License.
--
-h1${uiLabelMap.WebtoolsExportFromDataSource}/h1
-br /
-p
-${uiLabelMap.WebtoolsXMLExportInfo}
-/p
+p${uiLabelMap.WebtoolsXMLExportInfo}/p
#if results?has_content
hr /
Adding a non existent SecurityPermission to a SecurityPermissionGroup
Hi, in the https://localhost:8443/webtools/control/EditSecurityGroupPermissionsscreen, using the Add Permission (manually) to Security Group form, it is possible to add a non existent SecurityPermission to a SecurityPermissionGroup. Is this correct? Shouldn't any permission always be defined properly in the SecurityPermission entity before being referenced in a SecurityPermissionGroup? Thank you, Bruno
Re: Adding a non existent SecurityPermission to a SecurityPermissionGroup
Hi Scott, many thanks for the pointer. This was definitively a well discussed topic. Personally I do not agree with how it it designed right now (with the no-fk) for this two reasons: 1) If a SecurityPermission has not its own entity record there will never be a description field where the user can understand (or remember) what that permission is supposed to be used for. 2) There is no check that an already defined PermissionId is not used again for a different purpose in a different part of the code. Thank you, Bruno 2011/4/13 Scott Gray scott.g...@hotwaxmedia.com http://ofbiz.135035.n4.nabble.com/security-permission-td154203.html#a154208 Regards Scott HotWax Media http://www.hotwaxmedia.com On 12/04/2011, at 10:38 PM, Bruno Busco wrote: Hi, in the https://localhost:8443/webtools/control/EditSecurityGroupPermissionsscreen , using the Add Permission (manually) to Security Group form, it is possible to add a non existent SecurityPermission to a SecurityPermissionGroup. Is this correct? Shouldn't any permission always be defined properly in the SecurityPermission entity before being referenced in a SecurityPermissionGroup? Thank you, Bruno
Re: My vision for the OFBiz Framework
Great! Thanks 2011/4/6 David E Jones d...@me.com The portal screens in OFBiz are really just database-driven dynamic screens. In Moqui they are called dynamic screens using the DynamicScreen* entities. While designed, this feature has been tabled for the 1.0 release and will be incorporated in a later release. You can see the entity definitions (commented out) in the ScreenEntities.xml file. -David On Apr 5, 2011, at 11:05 PM, Bruno Busco wrote: Hi David, I downloaded the beta and seen a great work! Looks like we will have soon a very good option to the actual OFBiz framework to think about. BTW, I couldn't find any implementation or plans regarding a portal/portlet feature. Will the moqui framework include this, or what? Regards, Bruno 2011/4/5 David E Jones d...@me.com On Apr 4, 2011, at 11:06 PM, Sam Hamilton wrote: Hi David, Congats on the beta release! You were asking for feature requests and today I ran across a java framework called Play they have a few of things that might be interesting: - they get their framework to compile java sources directly and then hot-reloads the JVM [1] Taking a quick look at things I wonder if they are using Groovy to treat .java files as .groovy files. In Moqui the recommendation is to just use Groovy anytime you need a script for a service or other things. Of course, Moqui isn't so Java-centric as it seems like Play is, so runtime reloading during development is more of an inherent part of the framework and recommended tools as opposed to something that has to be added. - their logging seems to be very clear and would speed up bug finding [1] [2] Yes, that is interesting. In OFBiz this is a HUGE problem because there is so much use of the hideous log rethrow pattern which results in the same, or very similar, stack trace being logged half a dozen times. One thing I've noticed about the use of Groovy in Moqui is that they do a good job of putting locations of things like scriptlets (including screen actions, etc) in the stack trace. On the other hand, the stack traces are HUGE because of all of the groovy proxy calls and such, and I've thought about writing something to filter those out... just haven't done it yet. I agree trimming out redundant stuff from the stack trace would be helpful, in addition to avoiding the redundant stack traces. - they have a module repo to specify third party hosted module repos [3] I'd like to do this sooner or later with Moqui and list addons or plugins, plus a document about how to create them (I couldn't find a doc like that for Play, maybe I didn't look hard enough). That framework has various means of supporting this right now, but I like the idea of creating a page to list addons/plugins, even if it starts out empty... ;) -David [1] - http://www.playframework.org/documentation/1.1.1/overview [2] - http://www.playframework.org/documentation/1.1.1/usability#aBetterusabilityisnotjustfornormalpeoplea [3] - http://www.playframework.org/documentation/1.1.1/modules#repository Sam On 3 Apr 2011, at 12:57, David E Jones wrote: The Introduction to Moqui Framework document is now ready and available do download through SourceForge: https://sourceforge.net/projects/moqui/files/ This document is meant for application developers, ie for the same people who would use Moqui. It is 12 pages with 2 diagrams and should be a quick read, but describes where everything is in the framework and from a high level how to do various things. BTW, feedback on this document and on the framework itself would both be most helpful... -David On Apr 2, 2011, at 12:17 PM, David E Jones wrote: That is a good question. The best way to get an idea of how things would look is to look at the example component (in runtime/component/example), the configuration files (default: framework/api/conf-default/MoquiDefaultConf.xml, environment-specific: runtime/conf/...), and the interface definitions for the API (framework/api/src/org/moqui/...). I'm working on a document now that describes the different parts of the framework and how the API is organized (Introduction to Moqui Framework) and hopefully I'll have that posted this weekend. -David On Apr 2, 2011, at 11:22 AM, Brett Palmer wrote: David, We are interested in this project. Let us know the best way to start playing with the framework and see how we could use it. We do a lot of custom applications and moqui sounds like a framework that could be used for this. Thanks again for your efforts. Brett On Sat, Apr 2, 2011 at 12:09 AM, David E Jones d...@me.com 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
Re: My vision for the OFBiz Framework
Hi David, I downloaded the beta and seen a great work! Looks like we will have soon a very good option to the actual OFBiz framework to think about. BTW, I couldn't find any implementation or plans regarding a portal/portlet feature. Will the moqui framework include this, or what? Regards, Bruno 2011/4/5 David E Jones d...@me.com On Apr 4, 2011, at 11:06 PM, Sam Hamilton wrote: Hi David, Congats on the beta release! You were asking for feature requests and today I ran across a java framework called Play they have a few of things that might be interesting: - they get their framework to compile java sources directly and then hot-reloads the JVM [1] Taking a quick look at things I wonder if they are using Groovy to treat .java files as .groovy files. In Moqui the recommendation is to just use Groovy anytime you need a script for a service or other things. Of course, Moqui isn't so Java-centric as it seems like Play is, so runtime reloading during development is more of an inherent part of the framework and recommended tools as opposed to something that has to be added. - their logging seems to be very clear and would speed up bug finding [1] [2] Yes, that is interesting. In OFBiz this is a HUGE problem because there is so much use of the hideous log rethrow pattern which results in the same, or very similar, stack trace being logged half a dozen times. One thing I've noticed about the use of Groovy in Moqui is that they do a good job of putting locations of things like scriptlets (including screen actions, etc) in the stack trace. On the other hand, the stack traces are HUGE because of all of the groovy proxy calls and such, and I've thought about writing something to filter those out... just haven't done it yet. I agree trimming out redundant stuff from the stack trace would be helpful, in addition to avoiding the redundant stack traces. - they have a module repo to specify third party hosted module repos [3] I'd like to do this sooner or later with Moqui and list addons or plugins, plus a document about how to create them (I couldn't find a doc like that for Play, maybe I didn't look hard enough). That framework has various means of supporting this right now, but I like the idea of creating a page to list addons/plugins, even if it starts out empty... ;) -David [1] - http://www.playframework.org/documentation/1.1.1/overview [2] - http://www.playframework.org/documentation/1.1.1/usability#aBetterusabilityisnotjustfornormalpeoplea [3] - http://www.playframework.org/documentation/1.1.1/modules#repository Sam On 3 Apr 2011, at 12:57, David E Jones wrote: The Introduction to Moqui Framework document is now ready and available do download through SourceForge: https://sourceforge.net/projects/moqui/files/ This document is meant for application developers, ie for the same people who would use Moqui. It is 12 pages with 2 diagrams and should be a quick read, but describes where everything is in the framework and from a high level how to do various things. BTW, feedback on this document and on the framework itself would both be most helpful... -David On Apr 2, 2011, at 12:17 PM, David E Jones wrote: That is a good question. The best way to get an idea of how things would look is to look at the example component (in runtime/component/example), the configuration files (default: framework/api/conf-default/MoquiDefaultConf.xml, environment-specific: runtime/conf/...), and the interface definitions for the API (framework/api/src/org/moqui/...). I'm working on a document now that describes the different parts of the framework and how the API is organized (Introduction to Moqui Framework) and hopefully I'll have that posted this weekend. -David On Apr 2, 2011, at 11:22 AM, Brett Palmer wrote: David, We are interested in this project. Let us know the best way to start playing with the framework and see how we could use it. We do a lot of custom applications and moqui sounds like a framework that could be used for this. Thanks again for your efforts. Brett On Sat, Apr 2, 2011 at 12:09 AM, David E Jones d...@me.com 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
[jira] [Resolved] (OFBIZ-4187) The lookup widget does not support the target-parameter tag anymore
[
https://issues.apache.org/jira/browse/OFBIZ-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Busco resolved OFBIZ-4187.
Resolution: Fixed
The lookup widget does not support the target-parameter tag anymore
---
Key: OFBIZ-4187
URL: https://issues.apache.org/jira/browse/OFBIZ-4187
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Bruno Busco
Assignee: Jacques Le Roux
The actual call_fieldlookup2 and call_fieldlookup3 javascript functions do
not accept the optional document.${formName}.${item}.value parameters that
are passed when one or more target-parameter tags are used in the lookup
widget.
This causes that the lookup screens do not receive the parameters.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OFBIZ-4187) The lookup widget does not support the target-parameter tag anymore
[
https://issues.apache.org/jira/browse/OFBIZ-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Busco closed OFBIZ-4187.
--
The lookup widget does not support the target-parameter tag anymore
---
Key: OFBIZ-4187
URL: https://issues.apache.org/jira/browse/OFBIZ-4187
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Bruno Busco
Assignee: Jacques Le Roux
The actual call_fieldlookup2 and call_fieldlookup3 javascript functions do
not accept the optional document.${formName}.${item}.value parameters that
are passed when one or more target-parameter tags are used in the lookup
widget.
This causes that the lookup screens do not receive the parameters.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Revision 894330
Adrian, I have no time now. Please do it yourself. -Bruno 2011/3/13 Adrian Crum adrian.c...@sandglass-software.com Ideally, the multi-column layout would be handled by the applications needing it - not by the decorator. But it has been that way for too long to change it now. A framework-only deployment can have applications too - the Example and Web Tools components are examples. Would you be willing to move the logic to the GlobalDecorator, or should I do that myself? -Adrian On 3/13/2011 12:05 PM, Bruno Busco wrote: Hi Adrian, when I did this change I supposed that left-column where only something related to applications. The global decorator only had visibility of a pre-body and a body section. The main purpose of the change was to get rid of the several variables and use the decorator feature. But I agree with you, at least I cannot remember of a particular reason for not having the logic in the GlobalDecorator. -Bruno 2011/3/13 Adrian Crumadrian.c...@sandglass-software.com From the Rev 894330 commit log: [OFBIZ-3274] - Using decorator sections to control the left-bar The leftbar content is now defined using the left-column ApplicationDecorator section instead of setting the variables leftbarScreenName, leftbarScreenLocation and MainColumnStyle. The logic that checks if the left-column section has content, and thus if a left column must be rendered, has been moved from the GlobalDecorator to the ApplicationDecorator. Why was the logic moved to the ApplicationDecorator? Because of that change, applications developed in a framework-only deployment do not render correctly because the necessary containers are missing. From my perspective, that change was not necessary - the logic should have stayed in the GlobalDecorator. -Adrian
Re: Revision 894330
Hi Adrian, when I did this change I supposed that left-column where only something related to applications. The global decorator only had visibility of a pre-body and a body section. The main purpose of the change was to get rid of the several variables and use the decorator feature. But I agree with you, at least I cannot remember of a particular reason for not having the logic in the GlobalDecorator. -Bruno 2011/3/13 Adrian Crum adrian.c...@sandglass-software.com From the Rev 894330 commit log: [OFBIZ-3274] - Using decorator sections to control the left-bar The leftbar content is now defined using the left-column ApplicationDecorator section instead of setting the variables leftbarScreenName, leftbarScreenLocation and MainColumnStyle. The logic that checks if the left-column section has content, and thus if a left column must be rendered, has been moved from the GlobalDecorator to the ApplicationDecorator. Why was the logic moved to the ApplicationDecorator? Because of that change, applications developed in a framework-only deployment do not render correctly because the necessary containers are missing. From my perspective, that change was not necessary - the logic should have stayed in the GlobalDecorator. -Adrian
Re: svn commit: r1078167 - /ofbiz/trunk/applications/product/config/ProductUiLabels.xml
Hi Marco, I think that the correct Italian label should be: value xml:lang=itSe un catalogo NON viene valorizzato con categorie, questo non verrà mostrato nell'albero Sfoglia cataloghi/categorie/value -Bruno 2011/3/4 mrisal...@apache.org Author: mrisaliti Date: Fri Mar 4 22:06:35 2011 New Revision: 1078167 URL: http://svn.apache.org/viewvc?rev=1078167view=rev Log: A missing Italian translation Modified: ofbiz/trunk/applications/product/config/ProductUiLabels.xml Modified: ofbiz/trunk/applications/product/config/ProductUiLabels.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/config/ProductUiLabels.xml?rev=1078167r1=1078166r2=1078167view=diff == --- ofbiz/trunk/applications/product/config/ProductUiLabels.xml (original) +++ ofbiz/trunk/applications/product/config/ProductUiLabels.xml Fri Mar 4 22:06:35 2011 @@ -9943,6 +9943,7 @@ property key=ProductBrowseCatalogeAndCategories value xml:lang=enBrowse Catalogs/Categories/value value xml:lang=frCatalogues/catégories/value +value xml:lang=itSfoglia cataloghi/categorie/value /property property key=ProductBrowseCategories value xml:lang=csVýběr skupiny výrobků/value @@ -10140,6 +10141,7 @@ property key=ProductCatalogEmptyWarning value xml:lang=enIf you don't populate a Catalog with Categories, it will not shown in the Browse Catalogs/Categories tree/value value xml:lang=frSi vous ne créez pas de catégories pour un catalogue, il n'apparaitra pas dans l'arbre des Catalogues/catégories/value +value xml:lang=itSe un catalogo viene valorizzato con categorie, questo non verrà mostrato nell'albero Sfoglia cataloghi/categorie/value /property property key=ProductCatalogAdministrationMainPage value xml:lang=deKatalogverwaltung Hauptseite/value
[jira] Commented: (OFBIZ-4187) The lookup widget does not support the target-parameter tag anymore
[
https://issues.apache.org/jira/browse/OFBIZ-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997188#comment-12997188
]
Bruno Busco commented on OFBIZ-4187:
Hi Jacques,
I discovered this bug while using the lookup widget in a my own application.
In any case, an example could be the lookup you get in:
https://localhost:8443/marketing/control/EditContactListParty?contactListId=9000partyId=DemoCustAgentfromDate=2001-05-13%2000:00:00.000
or any other you can find searching for target-parameter
The lookup widget does not support the target-parameter tag anymore
---
Key: OFBIZ-4187
URL: https://issues.apache.org/jira/browse/OFBIZ-4187
Project: OFBiz
Issue Type: Bug
Components: framework
Reporter: Bruno Busco
Assignee: Jacques Le Roux
The actual call_fieldlookup2 and call_fieldlookup3 javascript functions do
not accept the optional document.${formName}.${item}.value parameters that
are passed when one or more target-parameter tags are used in the lookup
widget.
This causes that the lookup screens do not receive the parameters.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
How to control the hot-deploy components loading order?
Hi, is in the framework any tool to set the order in which the hot-deploy components are loaded? I have created two components in the hot-deploy folder. The first component loads some extseed in the database and the second component loads some other extseed that depends on the first one. Unfortunately the order on which they are loaded when I use the ant run-install-extseed command is the alphabetic order and the second one is loaded before the first resulting in a foreign-key error. How can I fix this? Thank you, Bruno
Re: How to control the hot-deploy components loading order?
Many thanks everyone for your hints. Adding the component-load.xml worked. I think we could add the following text to the readme.txt file in the hot-deploy directory: == The hot-deploy Auto-Loading feature loads all components in the order they are found (i.e. alphabetic or creation date). If you need a specific loading order of these components than you should disable the Auto-Loading feature by creating a component-load.xml file in the hot-deploy directory and use the load-component tag to load your component in the order you want (just use the component-load.xml file in the application folder as a template). == WDYT? -Bruno 2011/2/19 Scott Gray scott.g...@hotwaxmedia.com There is an unimplemented depends-on tag in ofbiz-component.xsd that I've been meaning to add support for which would solve this problem. It's not a trivial implementation though because at the moment components are loaded as they are located while this feature would require them all to be located first and then reordered and loaded. Regards Scott HotWax Media http://www.hotwaxmedia.com On 19/02/2011, at 5:31 AM, Bruno Busco wrote: Hi, is in the framework any tool to set the order in which the hot-deploy components are loaded? I have created two components in the hot-deploy folder. The first component loads some extseed in the database and the second component loads some other extseed that depends on the first one. Unfortunately the order on which they are loaded when I use the ant run-install-extseed command is the alphabetic order and the second one is loaded before the first resulting in a foreign-key error. How can I fix this? Thank you, Bruno
[jira] Created: (OFBIZ-4187) The lookup widget does not support the target-parameter tag anymore
The lookup widget does not support the target-parameter tag anymore
---
Key: OFBIZ-4187
URL: https://issues.apache.org/jira/browse/OFBIZ-4187
Project: OFBiz
Issue Type: Bug
Components: framework
Reporter: Bruno Busco
The actual call_fieldlookup2 and call_fieldlookup3 javascript functions do not
accept the optional document.${formName}.${item}.value parameters that are
passed when one or more target-parameter tags are used in the lookup widget.
This causes that the lookup screens do not receive the parameters.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OFBIZ-3373) Adding menu merging feature
[ https://issues.apache.org/jira/browse/OFBIZ-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988571#action_12988571 ] Bruno Busco commented on OFBIZ-3373: Hi Scott, is there something I can do to help finalizing this? Thank you, Bruno Adding menu merging feature --- Key: OFBIZ-3373 URL: https://issues.apache.org/jira/browse/OFBIZ-3373 Project: OFBiz Issue Type: Wish Components: framework Reporter: Bruno Busco Priority: Minor Attachments: googlebase-inject.patch, injections.patch, injections.patch, links.jpg, partymenu.JPG Hi devs, while discussing in the ML about modules and framework separation I thought to this new feature that I would like to discuss here with you. We have now the possibility to extend a menu from one other. This is great in order to have an high level of code reuse and great consistency all over OFBiz. I was thinking to a sort of merges-to property for the menu widget. This would allow a new module to specify an already exixting menu name (in the framework core or in a lower level module) that should be somewhat changed by the actual menu. For instance, in the attached image partymenu.jpg there is a a tipical use of this feature: in the party module there are lot of links that co to order application, account etc. Those menu link could be used defining a simple menu (say it partylinks_menu) in the party application that contains only party or framework related links (i.e. profile); additional components like order or accounting could define more menus that merges-to the partylinks_manu so that when the menu is rendered IN THE PARTY APPLICATION the new menu items added in the order and accounting applications are also rendered. This would allow us to dramatically reduce the component dependence and help us to have the framework-only distribution. To eventually implement this I think there should be an entity that defines such mergin menus and the menu rendered should lookup the entity to check if one or more merges to the actually rendering menu is defined. I would appreciate to hear from you if this idea can help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Could we remove button-style-1 and button-style-2 ?
Hi, again on this topic. I have seen that in the new Flat grey theme the button-style-1 and button-style-2 are rendered in the same way. I agree on this and was going to do the same on the Tomahawk theme. While doing this I asked myself if it does make sense to keep those two styles. They seems to be intended to be used to differentiate between intra-app and inter-app links. But why an user should be aware of the matter that a link is an intra-app or inter-app ? Shouldn't it be completely transparent to him? I think that keeping these styles is only confusing and I would like to remove it. Moreover we should go toward style names that describe element functions and not their apparence. For example the create, delete, search, refresh button styles have not been defined as button-with-plus, button-with-cross, button-with-maglens etc. The new Demo page layout is a great tool to test themes. It could also work as a style dictionary having all allowed styles present on the page and specifiyng that only styles present in this page should be used in the rest of the code. Does anybody see any issue if we get rid of the button-style-1 and button-style-2 styles? Thank you, Bruno
[jira] Commented: (OFBIZ-4127) Styles for the button-bar buttons are not created
[ https://issues.apache.org/jira/browse/OFBIZ-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988464#action_12988464 ] Bruno Busco commented on OFBIZ-4127: Hi, I have posted something in the DEV ML and later I have seen this JIRA. Well, could we definitively remove these two button-styles? There is no reason IMO to let the user know that a button links to intra-app or inter-app. The only reason the user should know about it is if it is not allowed to access a different applicationbut, in this case, a disabled button should be used (or no button at all). In any case if we would keep these styles they should better be named intra-app-button and inter-app-button. This means use functional names for styles. Styles for the button-bar buttons are not created - Key: OFBIZ-4127 URL: https://issues.apache.org/jira/browse/OFBIZ-4127 Project: OFBiz Issue Type: Bug Components: themes Affects Versions: SVN trunk Reporter: Erwan de FERRIERES Assignee: Adrian Crum Priority: Minor Fix For: SVN trunk Attachments: disabledBtn.patch, fg_button-bar.png The buttons in button-bar have no style definition. You can see it through the screenshot, or going to the layout demo page (nice idea, BTW!). Cheers, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r1065018 - in /ofbiz/trunk/framework/webtools: config/WebtoolsUiLabels.xml widget/MiscScreens.xml
Adrian,
I thougth this was usefull above all when different styles are rendered in
the same way (i.e. h4, h5, h6).
In this case, having different texts, helps understanding very easily even
if not looking at the markup.
-Bruno
2011/1/29 Adrian Crum adrian.c...@sandglass-software.com
Bruno,
At first glance, it might seem logical to have text describing each of the
styles or elements being displayed, but it really isn't necessary - since
the styles/elements can be seen when viewing the markup.
-Adrian
On 1/29/2011 6:22 AM, bus...@apache.org wrote:
Author: buscob
Date: Sat Jan 29 14:22:28 2011
New Revision: 1065018
URL: http://svn.apache.org/viewvc?rev=1065018view=rev
Log:
Added other button styles in the Layout demo.
Added Italian localization.
Modified:
ofbiz/trunk/framework/webtools/config/WebtoolsUiLabels.xml
ofbiz/trunk/framework/webtools/widget/MiscScreens.xml
Modified: ofbiz/trunk/framework/webtools/config/WebtoolsUiLabels.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/webtools/config/WebtoolsUiLabels.xml?rev=1065018r1=1065017r2=1065018view=diff
==
--- ofbiz/trunk/framework/webtools/config/WebtoolsUiLabels.xml (original)
+++ ofbiz/trunk/framework/webtools/config/WebtoolsUiLabels.xml Sat Jan 29
14:22:28 2011
@@ -2444,9 +2444,11 @@
/property
property key=WebtoolsLayoutDemo
value xml:lang=enLayout Demo/value
+value xml:lang=itDimostrazione Layout/value
/property
property key=WebtoolsLayoutDemoText
value xml:lang=enDemonstrate layout best practices and
provide a visual theme test page./value
+value xml:lang=itDimostrazione di come utilizzare gli stili e pagina
per il test dei temi visuali./value
/property
property key=WebtoolsLeaveAllEntriesBlank
value xml:lang=dealle Einträge leer lassen/value
Modified: ofbiz/trunk/framework/webtools/widget/MiscScreens.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/webtools/widget/MiscScreens.xml?rev=1065018r1=1065017r2=1065018view=diff
==
--- ofbiz/trunk/framework/webtools/widget/MiscScreens.xml (original)
+++ ofbiz/trunk/framework/webtools/widget/MiscScreens.xml Sat Jan 29
14:22:28 2011
@@ -111,6 +111,9 @@ under the License.
container style=button-bar
button-style-1
!-- Typically used for
intra-app links --
link
target=${demoTargetUrl} text=${uiLabelMap.CommonNew} style=create/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonDelete}
style=delete/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonRefresh}
style=refresh/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonSearch}
style=search/
link
target=${demoTargetUrl} text=${uiLabelMap.CommonSelected}
style=selected/
link
target=${demoTargetUrl} text=${uiLabelMap.CommonEnabled}/
link
text=${uiLabelMap.CommonDisabled} style=disabled/
@@ -118,6 +121,9 @@ under the License.
container style=button-bar
button-style-2
!-- Typically used for
inter-app links --
link
target=${demoTargetUrl} text=${uiLabelMap.CommonNew} style=create/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonDelete}
style=delete/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonRefresh}
style=refresh/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonSearch}
style=search/
link
target=${demoTargetUrl} text=${uiLabelMap.CommonSelected}
style=selected/
link
target=${demoTargetUrl} text=${uiLabelMap.CommonEnabled}/
link
text=${uiLabelMap.CommonDisabled} style=disabled/
@@ -127,12 +133,12 @@ under the License.
section name=h1-h6 Styles
widgets
horizontal-separator/
-label style=h1 text=${demoText}/
-label style=h2 text=${demoText}/
-label style=h3 text=${demoText}/
-label style=h4 text=${demoText}/
-label style=h5 text=${demoText}/
-label style=h6 text=${demoText}/
+label style=h1 text=${demoText} (h1)/
+label style=h2 text=${demoText} (h2)/
+label style=h3 text=${demoText} (h3)/
+label style=h4 text=${demoText} (h4)/
+label style=h5 text=${demoText} (h5)/
+label style=h6 text=${demoText} (h6)/
/widgets
/section
section name=Form/List Styles
Re: Could we remove button-style-1 and button-style-2 ?
Adrian, I am sorry to put again this on the table. I know we have already discussed about but I think that you are trying to better explain over and over a wrong concept. You can see how it is wrong when you say In the original visual theme, the tab-bar decorator was used for the sub-menu at the top of the main content area, button-style-1 was used for intra-app links, and button-style-2 was used for inter-app links. It cannot be a visual theme to use a decorator for a sub-menu, button-style-1 for intra-app links etc. It is the application itself. So why the application should decide which style should be used for a sub-menu? It should only identify the sub-menu as a sub-menu and then the visual theme should decide to decorate the sub-menu with a specific visual aspect. If the application developer A is free to use button-style-1 for intra-app links and button-style-2 for inter-app links then application developer B would be free to use button-style-1, let me say, for backoffice links and button-style-2 for ecommerce web site links. Then how could a visual theme designer create a graphics that somehow helps the user to distinguish between links? He could not do anything, he will understand that if the two decoration classes have not the same CSS the links will appear different without a clear reason and so we will have that the two classes will be, in a proper designed theme, with the same CSS. We are moving now towards having more visual themes hosted separately from the main trunk. If we do not clear away those ambiguity we will never have a solid base in the main trunk to let external visual themes to rely on. So my suggestion is to change all style names that do not describe element functionality but visual aspect. Of course I get your suggestion to spend some time removing box* styles but they should not be the only one to leave. -Bruno 2011/1/29 Adrian Crum adrian.c...@sandglass-software.com I'm sure we discussed this just a few weeks ago, but I will go over it again... The button-style-1 and button-style-2 CSS classes are button-bar class decorators. The button-bar class has other decorators too - tab-bar and tool-bar. Altogether, there are four button-bar decorators. The button-bar decorators were not intended to be used alone to style links, but they have been used that way recently and I have been fixing those instances as I come across them. Setting up the CSS classes this way gives the graphic artist some flexibility in styling the buttons. Attributes that all button bars have in common (spacing, positioning, orientation) can be applied to the button-bar class, and then the various decorators can have attributes that make them unique. It is up to the application developer to decide what the various button-bar decorators represent. The decorators have no inherent purpose - they simply provide the developer with some choices. In the original visual theme, the tab-bar decorator was used for the sub-menu at the top of the main content area, button-style-1 was used for intra-app links, and button-style-2 was used for inter-app links. I see no reason to remove any of the button-bar decorators. The decorators give the developer and graphic artist a palette of choices. That same concept gives us a choice of table header styles, table grid styles, etc. If there is an interest in removing unnecessary styles, then (in my opinion) that effort should be invested in removing the deprecated CSS styles. You can find them listed at the bottom of the Flat Grey maincss.css file. Removing the box* styles would be a good place to start. -Adrian On 1/29/2011 6:46 AM, Bruno Busco wrote: Hi, again on this topic. I have seen that in the new Flat grey theme the button-style-1 and button-style-2 are rendered in the same way. I agree on this and was going to do the same on the Tomahawk theme. While doing this I asked myself if it does make sense to keep those two styles. They seems to be intended to be used to differentiate between intra-app and inter-app links. But why an user should be aware of the matter that a link is an intra-app or inter-app ? Shouldn't it be completely transparent to him? I think that keeping these styles is only confusing and I would like to remove it. Moreover we should go toward style names that describe element functions and not their apparence. For example the create, delete, search, refresh button styles have not been defined as button-with-plus, button-with-cross, button-with-maglens etc. The new Demo page layout is a great tool to test themes. It could also work as a style dictionary having all allowed styles present on the page and specifiyng that only styles present in this page should be used in the rest of the code. Does anybody see any issue if we get rid of the button-style-1 and button-style-2 styles? Thank you, Bruno
Re: svn commit: r1065018 - in /ofbiz/trunk/framework/webtools: config/WebtoolsUiLabels.xml widget/MiscScreens.xml
Yes, you are right, the page title should be changed as well.
I did not change it yet because I was using the Tomahawk theme and, in this
theme, the page title is not visible because it is already present in the
breadcrumb.
The logic should be this:
- for all styles that are rendered as simple strings on the page, the style
should be added to the displyed text.
- for styles that are part of a table, a menu, a screenlet, a form header,
that is something whose function is clearly understandable from the page it
is not necessary to add the style to the displayed string.
-Bruno
2011/1/29 Adrian Crum adrian.c...@sandglass-software.com
Using the same logic, the page title should say Layout Demo (page-title)
because it is rendered in the same way as h1.
The whole point of the screen is to look at the markup - to understand how
a screen's markup is composed and how various styles are applied. In other
words, if you want to use the Layout Demo screen as a tool, then looking at
the markup is required - not optional.
-Adrian
On 1/29/2011 12:53 PM, Bruno Busco wrote:
Adrian,
I thougth this was usefull above all when different styles are rendered in
the same way (i.e. h4, h5, h6).
In this case, having different texts, helps understanding very easily even
if not looking at the markup.
-Bruno
2011/1/29 Adrian Crumadrian.c...@sandglass-software.com
Bruno,
At first glance, it might seem logical to have text describing each of
the
styles or elements being displayed, but it really isn't necessary - since
the styles/elements can be seen when viewing the markup.
-Adrian
On 1/29/2011 6:22 AM, bus...@apache.org wrote:
Author: buscob
Date: Sat Jan 29 14:22:28 2011
New Revision: 1065018
URL: http://svn.apache.org/viewvc?rev=1065018view=rev
Log:
Added other button styles in the Layout demo.
Added Italian localization.
Modified:
ofbiz/trunk/framework/webtools/config/WebtoolsUiLabels.xml
ofbiz/trunk/framework/webtools/widget/MiscScreens.xml
Modified: ofbiz/trunk/framework/webtools/config/WebtoolsUiLabels.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/webtools/config/WebtoolsUiLabels.xml?rev=1065018r1=1065017r2=1065018view=diff
==
--- ofbiz/trunk/framework/webtools/config/WebtoolsUiLabels.xml
(original)
+++ ofbiz/trunk/framework/webtools/config/WebtoolsUiLabels.xml Sat Jan
29
14:22:28 2011
@@ -2444,9 +2444,11 @@
/property
property key=WebtoolsLayoutDemo
value xml:lang=enLayout Demo/value
+value xml:lang=itDimostrazione Layout/value
/property
property key=WebtoolsLayoutDemoText
value xml:lang=enDemonstrate layout best practices and
provide a visual theme test page./value
+value xml:lang=itDimostrazione di come utilizzare gli stili e
pagina
per il test dei temi visuali./value
/property
property key=WebtoolsLeaveAllEntriesBlank
value xml:lang=dealle Einträge leer lassen/value
Modified: ofbiz/trunk/framework/webtools/widget/MiscScreens.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/webtools/widget/MiscScreens.xml?rev=1065018r1=1065017r2=1065018view=diff
==
--- ofbiz/trunk/framework/webtools/widget/MiscScreens.xml (original)
+++ ofbiz/trunk/framework/webtools/widget/MiscScreens.xml Sat Jan 29
14:22:28 2011
@@ -111,6 +111,9 @@ under the License.
container style=button-bar
button-style-1
!-- Typically used for
intra-app links --
link
target=${demoTargetUrl} text=${uiLabelMap.CommonNew}
style=create/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonDelete}
style=delete/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonRefresh}
style=refresh/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonSearch}
style=search/
link
target=${demoTargetUrl} text=${uiLabelMap.CommonSelected}
style=selected/
link
target=${demoTargetUrl} text=${uiLabelMap.CommonEnabled}/
link
text=${uiLabelMap.CommonDisabled} style=disabled/
@@ -118,6 +121,9 @@ under the License.
container style=button-bar
button-style-2
!-- Typically used for
inter-app links --
link
target=${demoTargetUrl} text=${uiLabelMap.CommonNew}
style=create/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonDelete}
style=delete/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonRefresh}
style=refresh/
+link target=${demoTargetUrl} text=${uiLabelMap.CommonSearch}
style=search/
link
Re: Could we remove button-style-1 and button-style-2 ?
Adrian I think we are almost on the same page, please read inline. 2011/1/30 Adrian Crum adrian.c...@sandglass-software.com The application developer designs the application, not the graphic artist. The graphic artist styles the application, he doesn't design it. 100% agreed For example, I am a developer designing a screen. The screen requires two sets of links. The links in set A all share something in common, and the links in set B all share something in common, but sets A and B have nothing in common. How do I indicate that to the user? I will use different styles for the two sets of links. IMO when a developer in this situation he should think: What is the functions of the links in set A and i set B?. Are they similar or equivalent to functions that already exist in the rest of the applications? For the set where the answer is yes than the link style should be the one used for that function in the other application. For the set where the answer is no than a new style should be defined with a name that describes the new function. What you're saying is that I am not allowed to make that decision - that is the theme designer's decision. I don't agree with that view. The theme designer is free to style set A and set B any way they want, but it is not their job to determine if set A or set B exist in the application. As explained above the developer is absolutely free to define new functional styles but FUNCTIONAL because, as you say, he is responsible for functions offered to the user, not of how they appear. So, for example, he is allowed to style a submit button with a confirm or a cancel style but he should never be allowed to attach a smallSubmit or a largeSubmit style to it. If the confirm buttons should appear smaller or greater than the cansel buttons is something that the graphic artist should decide. As an application developer, I want the option to use different styles to provide different visual cues to the user. You will have this option as explained. The graphic artist will help you to have it consistent in all the applications. I agree that some of the styles have been named poorly. We should rename them if that is the case, but we shouldn't get rid of them. The process can be gradual. I am trying to have a common agreement first so that we will not fight for every style changed or removed. So moving on, we should agree on the rationale behind it than make a list of styles to be removed or changed toghether with new functional names to be used all over the application and then gradually proceed in inplementing. Thank you for you help on this. -Bruno -Adrian On 1/29/2011 2:35 PM, Bruno Busco wrote: Adrian, I am sorry to put again this on the table. I know we have already discussed about but I think that you are trying to better explain over and over a wrong concept. You can see how it is wrong when you say In the original visual theme, the tab-bar decorator was used for the sub-menu at the top of the main content area, button-style-1 was used for intra-app links, and button-style-2 was used for inter-app links. It cannot be a visual theme to use a decorator for a sub-menu, button-style-1 for intra-app links etc. It is the application itself. So why the application should decide which style should be used for a sub-menu? It should only identify the sub-menu as a sub-menu and then the visual theme should decide to decorate the sub-menu with a specific visual aspect. If the application developer A is free to use button-style-1 for intra-app links and button-style-2 for inter-app links then application developer B would be free to use button-style-1, let me say, for backoffice links and button-style-2 for ecommerce web site links. Then how could a visual theme designer create a graphics that somehow helps the user to distinguish between links? He could not do anything, he will understand that if the two decoration classes have not the same CSS the links will appear different without a clear reason and so we will have that the two classes will be, in a proper designed theme, with the same CSS. We are moving now towards having more visual themes hosted separately from the main trunk. If we do not clear away those ambiguity we will never have a solid base in the main trunk to let external visual themes to rely on. So my suggestion is to change all style names that do not describe element functionality but visual aspect. Of course I get your suggestion to spend some time removing box* styles but they should not be the only one to leave. -Bruno 2011/1/29 Adrian Crumadrian.c...@sandglass-software.com I'm sure we discussed this just a few weeks ago, but I will go over it again... The button-style-1 and button-style-2 CSS classes are button-bar class decorators. The button-bar class has other decorators too - tab-bar and tool-bar. Altogether, there are four button-bar decorators. The button-bar
Re: [VOTE] [RELEASE] Apache OFBiz 09.04.01
+1 2011/1/20 Ashish Vijaywargiya vijaywargiya.ash...@gmail.com +1 -- Ashish On Thu, Jan 20, 2011 at 9:59 PM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: This is the vote thread to release a bug fix release for the 09.04 branch. This bug fix release and will supersede the release Apache OFBiz 09.04 and will be released as Apache OFBiz 09.04.01. The files can be downloaded from here: http://people.apache.org/~jacopoc/dist/http://people.apache.org/%7Ejacopoc/dist/ (please help to test the zip file and its signatures). Vote: [ +1] release as Apache OFBiz 09.04.01 [ -1] do not release For more details about this process please read this http://www.apache.org/foundation/voting.html Kind Regards, Jacopo
Re: Should we release a bug fix release for 09.04?
Of course I guess Jacopo intended 09.04.01 actually. -Bruno 2011/1/19 BJ Freeman bjf...@free-man.net there is a distinct difference between 10.04 and 9.04 so a bug fix release would be 9.04.01 = 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 Jacopo Cappellato sent the following on 1/19/2011 8:38 AM: Should we vote and release a bug fix release for the 09.04 series? This will be Apache OFBiz 10.04.01 (right?) and will supersede Apache OFBiz 09.04. I am not personally interested in this, and of course there is no hurry for a new release, but I know that some committers spent a lot of time backporting fixes to that branch, and if we think it is a good time for a bug fix release I would be happy to start another release process. Kind regards, Jacopo
Re: Updated Flat Grey Visual Theme
Hi Erik,
where can we see your prototipe of what you mean for shitched around search
area?
Did you attach a jpg somewhere?
-Bruno
2011/1/19 Erik Schuessler e...@brainfood.com
Excellent. I can come up with a design improvement comp to get started.
What do you all think about the idea of switching around the search areas?
It is a user interface thing.
Thanks
E
On 1/18/2011 11:48 AM, Adrian Crum wrote:
Any help would be appreciated! Just create a Jira issue and upload your
images/patches there. I've been applying little tweaks here and there, but
I'm no artist - so I would feel more comfortable with an artist making the
changes instead of me.
-Adrian
On 1/18/2011 9:27 AM, Erik Schuessler wrote:
This is a nice clean theme. I am happy to help out on polishing up the look
and
feel.
One thing that has always bugged me for user interface is the search area.
It
seems like we could modify the search area as an expandable bar over a side
menu, when I have used the back end, the catalog browse is more useful to
me
over some of the advanced search options. Granted, the main search is very
useful so it gets priority, however the but all of the advanced searches
are not.
I have attached a picture of what I am talking about. Just my two bits.
Thanks
Erik
One issue that I would like to see change is to move the
On 1/17/2011 4:41 PM, Jacques Le Roux wrote:
Yes that makes sense. And anyway if they prefer another theme they have
now
the choice. It's ok with me
Jacques
Ryan Foster wrote:
I guess it really just comes down to the approach. The objective of the
task
was to update the Flat Grey theme. So, I
approached the design as a realign rather than a redesign. I did not look
at
any other themes as examples, I simply focused on
how Flat Grey looked and functioned and then tried to make the smallest
amount of CSS and markup changes possible in order to
achieve the objective and stay with the scope of the task.
I understand your bias, because I have it as well, as probably every other
active OFBiz developer does. But for the average
user, the vast majority are going to select one language, one time zone,
and
one theme and then never touch this section again. Also, for a developer
deploying OFBiz across a large organization, they may even decide to set
these preferences globally across
the entire organization and not allow the user to have these selections.
In
that case, it becomes much easier for them because
they can simply disable the footer in the theme and it does not affect
anything else at all.
Ryan L. Foster
801.671.0769
cont...@ryanlfoster.com
ryanlfoster.com
On Jan 17, 2011, at 11:07 AM, Jacques Le Roux wrote:
Ryan Foster wrote:
That was exactly what I was trying to do. It seemed even more weird to me
to have theme selection and language in the header,
but have timezone selection in the footer and to have half of the
application links in the header and the other half in the
footer. The new grouping is much more logical in my opinion. All of the
applications are now grouped together in the header,
and all of the user preference selections, which are secondary, are
grouped
together in the footer.
That was true for the old Flat Grey but what about how it's handled in
Tomahawk for instance. Maybe I'm biased though because
for testing purpose I'm always switching languages and themes... BTW the
time zone selection is missing in Tomahawk...
Jacques
Ryan L. Foster
801.671.0769
cont...@ryanlfoster.com
ryanlfoster.com
On Jan 17, 2011, at 7:30 AM, Adrian Crum wrote:
Ryan can answer that question. I believe he was trying to keep the
masthead small so there is more room for the main content.
-Adrian
--- On Mon, 1/17/11, Jacques Le Roux (JIRA)j...@apache.orgj...@apache.org
wrote:
Also I asked
{quote}
BTW I was surprised that Ryan and you put the access to
preferences and languages features in the footer. It's not
always visible and seems a bit weird to me
{quote}
Any answers? ;)
--
Brainfood - We Think. We're Smart.
*Erik A. Schuessler*
Creative Partner
Street Address:
4004 East Side Ave.
Dallas, TX
75226
www.brainfood.comhttp://www.brainfood.com http://www.brainfood.com
TEL: 214.720.0700 e323
MOBILE: 214.893.3514
FAX: 214.893.3514
EMAIL:
e...@brainfood.commaito:e...@brainfood.commaito:e...@brainfood.com
Brainfood - We Think. We're Smart.
--
[image: Brainfood - We Think. We're Smart.]
*Erik A. Schuessler*
Creative Partner
Street Address: 4004 East Side Ave. Dallas, TX 75226
www.brainfood.com TEL: 214.720.0700 e323 MOBILE: 214.893.3514 FAX:
214.893.3514 EMAIL: e...@brainfood.com [image: Brainfood - We Think.
We're Smart.]
Re: svn commit: r1060701 - /ofbiz/trunk/framework/common/widget/CommonScreens.xml
At the end you got it! ;-)
Could we do the same for the search results screenlet so that we close these
issues ?
https://issues.apache.org/jira/browse/OFBIZ-3142
https://issues.apache.org/jira/browse/OFBIZ-1879
Thank you
-Bruno
2011/1/19 adri...@apache.org
Author: adrianc
Date: Wed Jan 19 07:39:16 2011
New Revision: 1060701
URL: http://svn.apache.org/viewvc?rev=1060701view=rev
Log:
Move Search Options text to screenlet title bar in the FindDecorator
screen. It's now visible when the screenlet is collapsed.
Modified:
ofbiz/trunk/framework/common/widget/CommonScreens.xml
Modified: ofbiz/trunk/framework/common/widget/CommonScreens.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/widget/CommonScreens.xml?rev=1060701r1=1060700r2=1060701view=diff
==
--- ofbiz/trunk/framework/common/widget/CommonScreens.xml (original)
+++ ofbiz/trunk/framework/common/widget/CommonScreens.xml Wed Jan 19
07:39:16 2011
@@ -483,10 +483,9 @@ under the License.
/section
decorator-section-include name=menu-bar/
container style=clear/
-screenlet id=searchOptions name=findScreenlet
collapsible=true
-label style=h2
text=${uiLabelMap.CommonSearchOptions}/
+screenlet id=searchOptions name=findScreenlet
collapsible=true title=${uiLabelMap.CommonSearchOptions}
container id=search-options
-decorator-section-include name=search-options/
+decorator-section-include name=search-options
/
/container
/screenlet
screenlet padded=false
Re: svn commit: r1060701 - /ofbiz/trunk/framework/common/widget/CommonScreens.xml
Oh I see, you are right.
The search result screenlet title bar is not visible because it is not
collapsible.
Leaving it as it is now there is no room wasting.
We have only a difference in the Search Options and Search Results
strings styles.
This would be removed if we move the Search Results label in the screenlet
title like you did for the search options.
-Bruno
2011/1/19 Adrian Crum adri...@hlmksw.com
There is no title bar in search results, so there is nothing to change.
-Adrian
On 1/19/2011 12:48 PM, Bruno Busco wrote:
At the end you got it! ;-)
Could we do the same for the search results screenlet so that we close
these
issues ?
https://issues.apache.org/jira/browse/OFBIZ-3142
https://issues.apache.org/jira/browse/OFBIZ-1879
Thank you
-Bruno
2011/1/19adri...@apache.org
Author: adrianc
Date: Wed Jan 19 07:39:16 2011
New Revision: 1060701
URL: http://svn.apache.org/viewvc?rev=1060701view=rev
Log:
Move Search Options text to screenlet title bar in the FindDecorator
screen. It's now visible when the screenlet is collapsed.
Modified:
ofbiz/trunk/framework/common/widget/CommonScreens.xml
Modified: ofbiz/trunk/framework/common/widget/CommonScreens.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/widget/CommonScreens.xml?rev=1060701r1=1060700r2=1060701view=diff
==
--- ofbiz/trunk/framework/common/widget/CommonScreens.xml (original)
+++ ofbiz/trunk/framework/common/widget/CommonScreens.xml Wed Jan 19
07:39:16 2011
@@ -483,10 +483,9 @@ under the License.
/section
decorator-section-include name=menu-bar/
container style=clear/
-screenlet id=searchOptions name=findScreenlet
collapsible=true
-label style=h2
text=${uiLabelMap.CommonSearchOptions}/
+screenlet id=searchOptions name=findScreenlet
collapsible=true title=${uiLabelMap.CommonSearchOptions}
container id=search-options
-decorator-section-include name=search-options/
+decorator-section-include name=search-options
/
/container
/screenlet
screenlet padded=false
[jira] Commented: (OFBIZ-4092) Update The Flat Grey Visual Theme
[ https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982778#action_12982778 ] Bruno Busco commented on OFBIZ-4092: This new Flat grey theme looks really good! Thank you guys. Update The Flat Grey Visual Theme - Key: OFBIZ-4092 URL: https://issues.apache.org/jira/browse/OFBIZ-4092 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Adrian Crum Assignee: Adrian Crum Priority: Minor Attachments: ac_flatgrey.patch, ac_flatgrey.patch, ac_images.zip, ac_images.zip, accounting800x600.png, brushed-aluminum.gif, catalog800x600.png, catalogManager.png, content800x600.png, contentManager.png, flatgrey.patch, flatgrey.patch, flatgrey.patch, flatgrey.patch, flatgrey.patch, images.zip, ofbiz_logo.gif, partyDetail.png, partyManager.png, rf_flatgrey.patch, rf_flatgrey_images.zip, screenshot.gif, timeSheet.png Update the Flat Grey visual theme. Design objectives: 1. Floating, flexible layout - screen can be resized. 2. Sight impaired accessible - users can change font size in their browser. 3. Supports RTL layout. 4. Does not require JavaScript. JavaScript can be used to add embellishments, but the theme can't depend on 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-4112) Page title missing in the Tomahawk theme.
[ https://issues.apache.org/jira/browse/OFBIZ-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982261#action_12982261 ] Bruno Busco commented on OFBIZ-4112: The main idea on the Tomahawk theme is that the navigation bar works both as a drop-down application selection menu and as a breadcrumbs indicator of the actually selected screen. The last part of the breadcrumbs (the one with the yellow background) shows the actually selected item from the Application Menu (headerItem). If the headerItem menu item takes to a multi-screen then a TabBar is shown and the information about the screen the user is actually using is given by the breadcrumb plus the selected tab in the TabBar. With this logic an additional title string in the screen itself seemed to not add any information to the user but only a waste of screen space. This was the reason I hided the title string. Page title missing in the Tomahawk theme. - Key: OFBIZ-4112 URL: https://issues.apache.org/jira/browse/OFBIZ-4112 Project: OFBiz Issue Type: Sub-task Reporter: Jacques Le Roux Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4112) Page title missing in the Tomahawk theme.
[ https://issues.apache.org/jira/browse/OFBIZ-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982271#action_12982271 ] Bruno Busco commented on OFBIZ-4112: Yes Jacques, this is wanted. While in an application main page the breadcrumbs ends with the application name and shows the menu icon to highight that more options are available. Page title missing in the Tomahawk theme. - Key: OFBIZ-4112 URL: https://issues.apache.org/jira/browse/OFBIZ-4112 Project: OFBiz Issue Type: Sub-task Reporter: Jacques Le Roux Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4112) Page title missing in the Tomahawk theme.
[
https://issues.apache.org/jira/browse/OFBIZ-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982272#action_12982272
]
Bruno Busco commented on OFBIZ-4112:
Of course this happens if the application main page is defined with
headerItem=main.
This does not happen actually with the example application.
I think we should change this since we normally use the example application as
a template.
This is the code in the appBarClose.ftl file:
#if headerItem!=main
div class=breadcrumbs-sep
${appModelMenu.getModelMenuItemByName(headerItem).getTitle(context)}
/div
/#if
Page title missing in the Tomahawk theme.
-
Key: OFBIZ-4112
URL: https://issues.apache.org/jira/browse/OFBIZ-4112
Project: OFBiz
Issue Type: Sub-task
Reporter: Jacques Le Roux
Priority: Minor
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4112) Page title missing in the Tomahawk theme.
[ https://issues.apache.org/jira/browse/OFBIZ-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982286#action_12982286 ] Bruno Busco commented on OFBIZ-4112: Yes, the Example application actually has not a proper main screen as i.e. Accounting does. There was discussion about using a PortalPage as the main screen of each application. May be we could discuss this in the ML and if approved we could use this pattern. I think we could close this. Page title missing in the Tomahawk theme. - Key: OFBIZ-4112 URL: https://issues.apache.org/jira/browse/OFBIZ-4112 Project: OFBiz Issue Type: Sub-task Reporter: Jacques Le Roux Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] [RELEASE] Apache OFBiz 10.04
+1 2011/1/14 Adrian Crum adrian.c...@yahoo.com +1 --- On Fri, 1/14/11, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Subject: [VOTE] [RELEASE] Apache OFBiz 10.04 To: dev@ofbiz.apache.org Date: Friday, January 14, 2011, 5:04 AM This is the vote thread to transform our release candidate 10.04 into an official release. This will be the first release of the 10.04 series (that contains the features up to 2010-04). The files can be downloaded from here: http://people.apache.org/~jacopoc/dist/http://people.apache.org/%7Ejacopoc/dist/ Vote: [ +1] release as Apache OFBiz 10.04 [ -1] do not release For more details about this process please read this http://www.apache.org/foundation/voting.html Kind Regards, Jacopo
Re: [jira] Commented: (OFBIZ-4092) Update The Flat Grey Visual Theme
In addition, when deprecating or selecting styles to be used we should better use style names that describe what the button IS in the screen and not HOW it should appear. So style names like .buttontextbig, .smallSubmit, .mediumSubmit, .largeSubmit, .button-style-1, .button-style-2, should not be used. Style names like: .buttontext, .loginButton, .button, input[type=reset], input[type=submit], input[type=button] are OK. In this way the theme can make a button larger or smaller than another button according to its function. My two cents. -Bruno 2011/1/12 Ryan Foster (JIRA) j...@apache.org [ https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980883#action_12980883] Ryan Foster commented on OFBIZ-4092: I tried deleting deprecated styles and letting things break when I created the BizznessTime theme... mostly just pissed people off. :) Update The Flat Grey Visual Theme - Key: OFBIZ-4092 URL: https://issues.apache.org/jira/browse/OFBIZ-4092 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Adrian Crum Assignee: Adrian Crum Priority: Minor Attachments: ac_flatgrey.patch, ac_images.zip, accounting800x600.png, brushed-aluminum.gif, catalog800x600.png, catalogManager.png, content800x600.png, contentManager.png, flatgrey.patch, flatgrey.patch, flatgrey.patch, flatgrey.patch, flatgrey.patch, images.zip, ofbiz_logo.gif, partyDetail.png, partyManager.png, screenshot.gif, timeSheet.png Update the Flat Grey visual theme. Design objectives: 1. Floating, flexible layout - screen can be resized. 2. Sight impaired accessible - users can change font size in their browser. 3. Supports RTL layout. 4. Does not require JavaScript. JavaScript can be used to add embellishments, but the theme can't depend on it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Discussion: UI Best Practices - Edit versus Update
Adrian, I would use Edit and Save. Thank you for your effort on improving consistency. -Bruno 2011/1/10 Jacques Le Roux jacques.le.r...@les7arts.com Adrian, I think we should focus on English, there already enough possible conflicts ;o) Jacques From: Adrian Crum adri...@hlmksw.com Jacques, Thank you for your comments! I thought we might have a problem setting up best practices for terminology - since the terms used will vary depending on the language. I am not sure how to proceed. If we continue in English, then the best practices will be English-centric. Maybe have a section for each language? The text of the term isn't as important as using it consistently. -Adrian On 1/10/2011 9:54 AM, Jacques Le Roux wrote: From: Adrian Crum adrian.c...@yahoo.com I updated the UI Best Practices Wiki page with the information from our last discussion about Create versus Add versus New. We ended up with +1 for Create, +2 for New, and +2 for Create New. I used the one common to all - Create New. Keep in mind this isn't set in stone - we can still change it. This sounds good to me, though for a purist in French it would be a pleonasm ;o) See the Terminology section: https://cwiki.apache.org/confluence/display/OFBADMIN/User+Interface+Layout+Best+Practices In this discussion, I would like for us to come up with a best practice for Edit/Update terminology. If the user is modifying existing data, what is the correct term to use in the UI? Edit? Modify? Update? Edit Existing? Update Existing? Or something else? Modify, but I'm certainly biased by my mother tongue While we are on that subject, what is the correct term to be used in the form's submit button? Save or Update? Save (but Update would be as good for me, only that in French it's Mettre à jour vs Enregistrer - Sauvegarder being too specific) Sorry, not sure my comments are hepful at all :/ Jacques Keep in mind there are no right or wrong answers, we are just trying to make the UI consistent. -Adrian
Re: Discussion: Flat Grey Visual Theme
The themes repository should not actually be a SVN repository but the https://cwiki.apache.org/confluence/display/OFBIZ/Visual+Themes+Gallery can be a right place to host them. Simpler, easier to access. -Bruno 2011/1/7 Jacques Le Roux jacques.le.r...@les7arts.com OK, that was the reason I had some concerns. Let's discuss it seriously... I think there are 2 ways to create a new themes from an existing one (a brand new one is not a problem). Duplicate an OOTB existing one and peek an poke there (resourceValues in ThemeNameThemeData.xml are all refering to locations in this theme) pros: independent from changes in the original theme (no pb if the theme dissapears, is changed for any reasons, etc.) cons: independent from changes in the original theme (you can't benefit from bug fixes, improvements, enhancements, etc.) Create a new theme by keeping references to an OOTB existing (some resourceValues in ThemeNameThemeData.xml are still refering to locations in this original theme) As (almost) ever there are 2 faces to the coin, the pros and cons are reversed from above. Which one are you using BJ? I guess the second. Else you would not have any concerns Jacques From: BJ Freeman bjf...@free-man.net Adrian i am sure as a business man you understand if it ain't broke don't fix it. Now if you talking about new themes I can agree, but no one has proposed any or give an price. = 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 Adrian Crum sent the following on 1/6/2011 3:23 PM: That can go both ways. If your deployments depends upon the visual themes being in the trunk, then perhaps you should fund their upkeep. -Adrian On 1/6/2011 2:58 PM, BJ Freeman wrote: so you will be glad to fund the effort to do that. Time is money. and anything the effects the ROI needs to be considered, if the software is to be widely accepted. = 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 Ryan Foster sent the following on 1/6/2011 2:51 PM: I completely agree with you BJ. Considerations definitely have to be made when things are removed, especially if they are tied to the framework. What is being discussed is whether to remove themes, which can be hot-deployed from being maintained in the trunk. For future releases, all you would need to do is manually add your themes, custom or otherwise, to your production instance. If they are no longer tied in svn to the trunk, they would not be effected by any updates or releases. Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Jan 6, 2011, at 3:40 PM, BJ Freeman wrote: so there will not be any more releases based on the trunk? I was speaking in the future when 11.04 or 12.04 happen. it is the disregard of those that actually use this software instead of just enjoy developing it. I am a developer second and a business man first. basically you can add all you want but when you want to remove you must consider those that have counted on what was provided. = 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 Bruno Busco sent the following on 1/6/2011 2:33 PM: The theme will still be present in the 10.04 releases. No production servers should rely on trunk. -Bruno 2011/1/6 BJ Freemanbjf...@free-man.net I have one that uses the flat grey as default so if I do an update from the svn the flat grey will and my customization disappear. my sas uses all those in the themes, with my modification. they will be removed. when the svn update is run. those are just a few examples. = 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 Bruno Busco sent the following on 1/6/2011 2:00 PM: I am sorry, BJ, I do not see your point. What could be the issue? We will have less themes to maintain in the trunk (just Flat Grey, Tomahawk, Default and Multiflex). We will have more people that will be able to maintain additional themes in the Themes Gallery. Production servers will have each one its selected theme (one of the OOTB, one of the Themes Gallery or a customized version of them). -Bruno 2011/1/6 BJ Freemanbjf...@free
Re: Discussion: Flat Grey Visual Theme
, BJ Freeman wrote: so there will not be any more releases based on the trunk? I was speaking in the future when 11.04 or 12.04 happen. it is the disregard of those that actually use this software instead of just enjoy developing it. I am a developer second and a business man first. basically you can add all you want but when you want to remove you must consider those that have counted on what was provided. = 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 Bruno Busco sent the following on 1/6/2011 2:33 PM: The theme will still be present in the 10.04 releases. No production servers should rely on trunk. -Bruno 2011/1/6 BJ Freemanbjf...@free-man.net I have one that uses the flat grey as default so if I do an update from the svn the flat grey will and my customization disappear. my sas uses all those in the themes, with my modification. they will be removed. when the svn update is run. those are just a few examples. = 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 Bruno Busco sent the following on 1/6/2011 2:00 PM: I am sorry, BJ, I do not see your point. What could be the issue? We will have less themes to maintain in the trunk (just Flat Grey, Tomahawk, Default and Multiflex). We will have more people that will be able to maintain additional themes in the Themes Gallery. Production servers will have each one its selected theme (one of the OOTB, one of the Themes Gallery or a customized version of them). -Bruno 2011/1/6 BJ Freemanbjf...@free-man.net how about those that are using ofbiz for SAS and will have many themes for their clients. Bruno Busco sent the following on 1/6/2011 12:51 PM: Yes, having more than one theme in the trunk was originally accepted in order to use and show the visual theme selection feature OOTB. Actually Bluelight, Dropping Crumbs and Tomahawk are one the evolution of the other. Each time we decided to create a new theme instead of replacing the one existing just to avoid problems to users. My proposal is to remove Bluelight, Dropping Crumbs and BizznessTime from the trunk and put them in a separate themes repository as suggested by Ryan. Remove the actual version of the Flat Grey from the trunk and put it in the themes repository. Improve the Flat Grey theme in the trunk with the work you guys are doing. In this way we will have in the trunk two themes for the backend (Actual FlatGrey and Tomahawk) and two themes for the ecommerce (Default and Multiflex). In the themes repository there will be Bluelight, Dropping Crumbs, BizznessTime and the actual FlatGrey. It could be a nice start for the theme repository (and gallery) start. -Bruno 2011/1/6 Jacques Le Rouxjacques.le.r...@les7arts.com Ryan Foster wrote: inline... Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Jan 6, 2011, at 11:38 AM, Jacques Le Roux wrote: Ryan Foster wrote: Jacques, I understand your concerns about support, and your thoughts on the themes has some valid points. However, in regards to the BizznessTime theme, I never really intended for that to be my theme anyway. I always viewed it as a community theme as that was it's original intent and it was truly a collaborative effort to build it between myself, my colleagues at HotWax, BrainFood, and other members of the the OFBiz community. Right, sorry for that Ryan. It's only because I know you were one of the fathers (the most important I guess) and helped much at the beginning, my apologies. At any rate, my time issues and focus have shifted significantly over the last few months as I have left HotWax and gone into independent consulting and freelance development. I plan on taking a much more active role in the community in the months and years ahead. That's really a good, very good news! As far as theme contributions go, I wonder if maybe it would be a good idea to have a theme repo outside of the trunk that individuals could commit to? The problem with theme maintenance once a new theme has been added to the trunk is that not everyone has commit privileges to the trunk. This makes the process of maintenance a lot more time consuming for individual contributors as they have to rely on patches, updates, collaboration, etc, rather than just monitoring and maintaining their own code. This could certainly be discussed as themes are no blocking parts as long as *at least one works perfectly* (another way is to become
Re: Discussion: Flat Grey Visual Theme
I a not saying that actual themes are dependent from each other. At least I am not aware of this dependency. I mean that, generally, a theme A is dependent from theme B than you cannot download theme A from the Theme Gallery and install it if you do not install theme B also. That simple. 2011/1/7 BJ Freeman bjf...@free-man.net to paraphrase what I think you said the current themes are not independent of each other so can not be removed, without causing failure in another The links you gave and the themes depository in wiki will not facilitate an end user on selecting or installing the themes from ofbiz like the current theme selection. again the rule is not to remove what is already put in Update and modify only. Now if all new themes are put in the themes gallery I see no problem with 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 Bruno Busco sent the following on 1/7/2011 4:06 AM: Dependencies between themes do not allow modular selection, distribution and installation. Please give a look to these web sites: http://www.templatemonster.com/magento-themes.php http://wordpress.org/extend/themes/ http://drupal.org/project/Themes they are all examples of how to maintain themes database. In a production installation one can choose between: - using one of the OOTB themes as it is - use one of the themes from the theme gallery as it is - start from one of the OOTB or gallery themes to build a new customized one Moving a theme from OOTB to the theme gallery should not be an issue. It simply slightly changes the way how a production server is updated. -Bruno 2011/1/7 Jacques Le Rouxjacques.le.r...@les7arts.com From: BJ Freemanbjf...@free-man.net more the second. however I am reacting more to a pattern change. for instance ecommerce was downgraded from a main app to a specialpurpose. I was not removed. the architecture lets it be moved with out any code changes to custom components already developed against it. Yes, I completly understand your point... And I guess you are not alone in this situation... related to themes, and multitenacy, not every user is going to want the same theme so the themes folder will be filled with `100's eventually. the script I started, https://issues.apache.org/jira/browse/OFBIZ-3490 is getting fancier. I can see templates for functionality of themes instead of the themes themselves. the seup app reads the data templateThemeData.xml and modifies it on the fly to the way the customer wants it. This way we don't have a lot of inactive themes and all the possibilities are in the template data. this is a flexible change once the Setup structure is in place. see https://issues.apache.org/jira/browse/OFBIZ-635 comment - 05/May/09 02:14 PM As I planned initially, to be discussed... Jacques = 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 Jacques Le Roux sent the following on 1/6/2011 11:15 PM: OK, that was the reason I had some concerns. Let's discuss it seriously... I think there are 2 ways to create a new themes from an existing one (a brand new one is not a problem). Duplicate an OOTB existing one and peek an poke there (resourceValues in ThemeNameThemeData.xml are all refering to locations in this theme) pros: independent from changes in the original theme (no pb if the theme dissapears, is changed for any reasons, etc.) cons: independent from changes in the original theme (you can't benefit from bug fixes, improvements, enhancements, etc.) Create a new theme by keeping references to an OOTB existing (some resourceValues in ThemeNameThemeData.xml are still refering to locations in this original theme) As (almost) ever there are 2 faces to the coin, the pros and cons are reversed from above. Which one are you using BJ? I guess the second. Else you would not have any concerns Jacques From: BJ Freemanbjf...@free-man.net Adrian i am sure as a business man you understand if it ain't broke don't fix it. Now if you talking about new themes I can agree, but no one has proposed any or give an price. = 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 Adrian Crum sent the following on 1/6/2011 3:23 PM: That can go both ways. If your deployments depends upon the visual themes being in the trunk
Re: Discussion: Flat Grey Visual Theme
You do bring up an interesting idea though... Say for instance we have just 2 themes in the OOTB installation with a link under the selection list that said get more themes. Clicking that would bring up a list of themes in an external themes repo. We could then have a script that allows the user to grab the external themes XML seed data and download the themes assets to their installed instance. Might be a good idea for a future enhancement. That's nice indeed !!
Re: Discussion: Flat Grey Visual Theme
Yes, it makes sense to have it configurable. 2011/1/7 BJ Freeman bjf...@free-man.net Please make that a configurable option, since in a SAS, muiltitenant environment that may not be advisable. = 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 Bruno Busco sent the following on 1/7/2011 11:54 AM: You do bring up an interesting idea though... Say for instance we have just 2 themes in the OOTB installation with a link under the selection list that said get more themes. Clicking that would bring up a list of themes in an external themes repo. We could then have a script that allows the user to grab the external themes XML seed data and download the themes assets to their installed instance. Might be a good idea for a future enhancement. That's nice indeed !!
[jira] Commented: (OFBIZ-4081) Form widget improvements
[ https://issues.apache.org/jira/browse/OFBIZ-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978241#action_12978241 ] Bruno Busco commented on OFBIZ-4081: Looking at other open source ERP systems I found that many of the improvement proposed here as sub-tasks are implemented in openCRX (http://demo.opencrx.org). I put here this reference because it could be usefull in our design. Form widget improvements Key: OFBIZ-4081 URL: https://issues.apache.org/jira/browse/OFBIZ-4081 Project: OFBiz Issue Type: Improvement Components: framework Reporter: Bruno Busco Priority: Minor I have a list of ideas about improvements that could be done on the frame widget. I think that creating jiras for these could be a good starting point to discuss, and eventually design and implement them. This issue is an umbrella task for them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4092) Update The Flat Grey Visual Theme
[ https://issues.apache.org/jira/browse/OFBIZ-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978243#action_12978243 ] Bruno Busco commented on OFBIZ-4092: I have an idea for the tab bar. We all agree that it does not show well when it comes to two or three rows. Well, we could only show the tabs that fit in one row and add a tab as last tab. When hovering on the tab the remaining tabs appear like a pull down menu allowing the user to select one of them. The actually selected tab should always be showed as the fist element on the left. What do you think? Could it be done with some jquery script? Update The Flat Grey Visual Theme - Key: OFBIZ-4092 URL: https://issues.apache.org/jira/browse/OFBIZ-4092 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Adrian Crum Assignee: Adrian Crum Priority: Minor Attachments: accounting800x600.png, catalog800x600.png, catalogManager.png, content800x600.png, contentManager.png, flatgrey.patch, flatgrey.patch, images.zip, ofbiz_logo.gif, partyDetail.png, partyManager.png, screenshot.gif, timeSheet.png Update the Flat Grey visual theme. Design objectives: 1. Floating, flexible layout - screen can be resized. 2. Sight impaired accessible - users can change font size in their browser. 3. Supports RTL layout. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Discussion: Flat Grey Visual Theme
Yes, having more than one theme in the trunk was originally accepted in order to use and show the visual theme selection feature OOTB. Actually Bluelight, Dropping Crumbs and Tomahawk are one the evolution of the other. Each time we decided to create a new theme instead of replacing the one existing just to avoid problems to users. My proposal is to remove Bluelight, Dropping Crumbs and BizznessTime from the trunk and put them in a separate themes repository as suggested by Ryan. Remove the actual version of the Flat Grey from the trunk and put it in the themes repository. Improve the Flat Grey theme in the trunk with the work you guys are doing. In this way we will have in the trunk two themes for the backend (Actual FlatGrey and Tomahawk) and two themes for the ecommerce (Default and Multiflex). In the themes repository there will be Bluelight, Dropping Crumbs, BizznessTime and the actual FlatGrey. It could be a nice start for the theme repository (and gallery) start. -Bruno 2011/1/6 Jacques Le Roux jacques.le.r...@les7arts.com Ryan Foster wrote: inline... Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Jan 6, 2011, at 11:38 AM, Jacques Le Roux wrote: Ryan Foster wrote: Jacques, I understand your concerns about support, and your thoughts on the themes has some valid points. However, in regards to the BizznessTime theme, I never really intended for that to be my theme anyway. I always viewed it as a community theme as that was it's original intent and it was truly a collaborative effort to build it between myself, my colleagues at HotWax, BrainFood, and other members of the the OFBiz community. Right, sorry for that Ryan. It's only because I know you were one of the fathers (the most important I guess) and helped much at the beginning, my apologies. At any rate, my time issues and focus have shifted significantly over the last few months as I have left HotWax and gone into independent consulting and freelance development. I plan on taking a much more active role in the community in the months and years ahead. That's really a good, very good news! As far as theme contributions go, I wonder if maybe it would be a good idea to have a theme repo outside of the trunk that individuals could commit to? The problem with theme maintenance once a new theme has been added to the trunk is that not everyone has commit privileges to the trunk. This makes the process of maintenance a lot more time consuming for individual contributors as they have to rely on patches, updates, collaboration, etc, rather than just monitoring and maintaining their own code. This could certainly be discussed as themes are no blocking parts as long as *at least one works perfectly* (another way is to become committer), opinions? I think the way that Magento and Wordpress do it are good examples. With Wordpress, there is one official theme that is included with the install, but there are literally thousands of themes that are not maintained by Wordpress that they list on there site http://wordpress.org/extend/themes/, and now with the 3.0 release you can even search for new themes and install them automatically from inside your Wordpress install. Doing it this way fosters wider community support by delegating maintenance of these themes to individual contributors rather than forcing it on a handful of committers and also allows developers to monetize there contributions by offering premium themes and plugins. In fact, there are many individuals and companies in the Wordpress community that make their living solely by selling themes and plugins. This furthers solidifies the base of support for the project by offering a mid-tier option for someone who wants something more than OOTB but can't necessarily afford custom development. This makes good sense indeed. The only difference, I guess, is unfortunately the width of the audience. This does not mean that we should not try... Jacques Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Jan 6, 2011, at 8:17 AM, Adrian Crum wrote: From my perspective, I don't see much chance in the Flat Grey visual theme being abandoned. Enough people use it that it will get the attention it needs. If Ryan isn't available to fix something, I can fix it. If I'm not available, someone else could fix it, etc. -Adrian On 1/6/2011 6:02 AM, Jacques Le Roux wrote: Ryan, Your screen copies at https://issues.apache.org/jira/browse/OFBIZ-4092 looks really great! Looking forward for the implementation... My concerns are that maybe you will not have enough time later to keep up with possible bugs or other issues. Look for instance what happened to Bizzness Time https://issues.apache.org/jira/browse/OFBIZ-2398. Even if it looks a bit old, we have a theme which works great. Why taking any risks with it? Also I can't see any issues with having more themes. The more we have the
Re: Discussion: Flat Grey Visual Theme
I am sorry, BJ, I do not see your point. What could be the issue? We will have less themes to maintain in the trunk (just Flat Grey, Tomahawk, Default and Multiflex). We will have more people that will be able to maintain additional themes in the Themes Gallery. Production servers will have each one its selected theme (one of the OOTB, one of the Themes Gallery or a customized version of them). -Bruno 2011/1/6 BJ Freeman bjf...@free-man.net how about those that are using ofbiz for SAS and will have many themes for their clients. Bruno Busco sent the following on 1/6/2011 12:51 PM: Yes, having more than one theme in the trunk was originally accepted in order to use and show the visual theme selection feature OOTB. Actually Bluelight, Dropping Crumbs and Tomahawk are one the evolution of the other. Each time we decided to create a new theme instead of replacing the one existing just to avoid problems to users. My proposal is to remove Bluelight, Dropping Crumbs and BizznessTime from the trunk and put them in a separate themes repository as suggested by Ryan. Remove the actual version of the Flat Grey from the trunk and put it in the themes repository. Improve the Flat Grey theme in the trunk with the work you guys are doing. In this way we will have in the trunk two themes for the backend (Actual FlatGrey and Tomahawk) and two themes for the ecommerce (Default and Multiflex). In the themes repository there will be Bluelight, Dropping Crumbs, BizznessTime and the actual FlatGrey. It could be a nice start for the theme repository (and gallery) start. -Bruno 2011/1/6 Jacques Le Rouxjacques.le.r...@les7arts.com Ryan Foster wrote: inline... Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Jan 6, 2011, at 11:38 AM, Jacques Le Roux wrote: Ryan Foster wrote: Jacques, I understand your concerns about support, and your thoughts on the themes has some valid points. However, in regards to the BizznessTime theme, I never really intended for that to be my theme anyway. I always viewed it as a community theme as that was it's original intent and it was truly a collaborative effort to build it between myself, my colleagues at HotWax, BrainFood, and other members of the the OFBiz community. Right, sorry for that Ryan. It's only because I know you were one of the fathers (the most important I guess) and helped much at the beginning, my apologies. At any rate, my time issues and focus have shifted significantly over the last few months as I have left HotWax and gone into independent consulting and freelance development. I plan on taking a much more active role in the community in the months and years ahead. That's really a good, very good news! As far as theme contributions go, I wonder if maybe it would be a good idea to have a theme repo outside of the trunk that individuals could commit to? The problem with theme maintenance once a new theme has been added to the trunk is that not everyone has commit privileges to the trunk. This makes the process of maintenance a lot more time consuming for individual contributors as they have to rely on patches, updates, collaboration, etc, rather than just monitoring and maintaining their own code. This could certainly be discussed as themes are no blocking parts as long as *at least one works perfectly* (another way is to become committer), opinions? I think the way that Magento and Wordpress do it are good examples. With Wordpress, there is one official theme that is included with the install, but there are literally thousands of themes that are not maintained by Wordpress that they list on there site http://wordpress.org/extend/themes/, and now with the 3.0 release you can even search for new themes and install them automatically from inside your Wordpress install. Doing it this way fosters wider community support by delegating maintenance of these themes to individual contributors rather than forcing it on a handful of committers and also allows developers to monetize there contributions by offering premium themes and plugins. In fact, there are many individuals and companies in the Wordpress community that make their living solely by selling themes and plugins. This furthers solidifies the base of support for the project by offering a mid-tier option for someone who wants something more than OOTB but can't necessarily afford custom development. This makes good sense indeed. The only difference, I guess, is unfortunately the width of the audience. This does not mean that we should not try... Jacques Jacques Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Jan 6, 2011, at 8:17 AM, Adrian Crum wrote: From my perspective, I don't see much chance in the Flat Grey visual theme being abandoned. Enough people use it that it will get the attention it needs. If Ryan isn't available to fix something, I can fix
Re: Discussion: Flat Grey Visual Theme
The theme will still be present in the 10.04 releases. No production servers should rely on trunk. -Bruno 2011/1/6 BJ Freeman bjf...@free-man.net I have one that uses the flat grey as default so if I do an update from the svn the flat grey will and my customization disappear. my sas uses all those in the themes, with my modification. they will be removed. when the svn update is run. those are just a few examples. = 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 Bruno Busco sent the following on 1/6/2011 2:00 PM: I am sorry, BJ, I do not see your point. What could be the issue? We will have less themes to maintain in the trunk (just Flat Grey, Tomahawk, Default and Multiflex). We will have more people that will be able to maintain additional themes in the Themes Gallery. Production servers will have each one its selected theme (one of the OOTB, one of the Themes Gallery or a customized version of them). -Bruno 2011/1/6 BJ Freemanbjf...@free-man.net how about those that are using ofbiz for SAS and will have many themes for their clients. Bruno Busco sent the following on 1/6/2011 12:51 PM: Yes, having more than one theme in the trunk was originally accepted in order to use and show the visual theme selection feature OOTB. Actually Bluelight, Dropping Crumbs and Tomahawk are one the evolution of the other. Each time we decided to create a new theme instead of replacing the one existing just to avoid problems to users. My proposal is to remove Bluelight, Dropping Crumbs and BizznessTime from the trunk and put them in a separate themes repository as suggested by Ryan. Remove the actual version of the Flat Grey from the trunk and put it in the themes repository. Improve the Flat Grey theme in the trunk with the work you guys are doing. In this way we will have in the trunk two themes for the backend (Actual FlatGrey and Tomahawk) and two themes for the ecommerce (Default and Multiflex). In the themes repository there will be Bluelight, Dropping Crumbs, BizznessTime and the actual FlatGrey. It could be a nice start for the theme repository (and gallery) start. -Bruno 2011/1/6 Jacques Le Rouxjacques.le.r...@les7arts.com Ryan Foster wrote: inline... Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Jan 6, 2011, at 11:38 AM, Jacques Le Roux wrote: Ryan Foster wrote: Jacques, I understand your concerns about support, and your thoughts on the themes has some valid points. However, in regards to the BizznessTime theme, I never really intended for that to be my theme anyway. I always viewed it as a community theme as that was it's original intent and it was truly a collaborative effort to build it between myself, my colleagues at HotWax, BrainFood, and other members of the the OFBiz community. Right, sorry for that Ryan. It's only because I know you were one of the fathers (the most important I guess) and helped much at the beginning, my apologies. At any rate, my time issues and focus have shifted significantly over the last few months as I have left HotWax and gone into independent consulting and freelance development. I plan on taking a much more active role in the community in the months and years ahead. That's really a good, very good news! As far as theme contributions go, I wonder if maybe it would be a good idea to have a theme repo outside of the trunk that individuals could commit to? The problem with theme maintenance once a new theme has been added to the trunk is that not everyone has commit privileges to the trunk. This makes the process of maintenance a lot more time consuming for individual contributors as they have to rely on patches, updates, collaboration, etc, rather than just monitoring and maintaining their own code. This could certainly be discussed as themes are no blocking parts as long as *at least one works perfectly* (another way is to become committer), opinions? I think the way that Magento and Wordpress do it are good examples. With Wordpress, there is one official theme that is included with the install, but there are literally thousands of themes that are not maintained by Wordpress that they list on there site http://wordpress.org/extend/themes/, and now with the 3.0 release you can even search for new themes and install them automatically from inside your Wordpress install. Doing it this way fosters wider community support by delegating maintenance of these themes to individual contributors rather than forcing it on a handful of committers and also allows developers to monetize there contributions by offering premium themes and plugins. In fact, there are many individuals
Re: Discussion: Flat Grey Visual Theme
As I said before, there are so many themes in the trunk right now just to avoid troubles to users. But we have seen that this is not a good way to manage themes in the long time. We need to break this chain now or we will have too many themes in the trunk. -Bruno 2011/1/6 Bruno Busco bruno.bu...@gmail.com The theme will still be present in the 10.04 releases. No production servers should rely on trunk. -Bruno 2011/1/6 BJ Freeman bjf...@free-man.net I have one that uses the flat grey as default so if I do an update from the svn the flat grey will and my customization disappear. my sas uses all those in the themes, with my modification. they will be removed. when the svn update is run. those are just a few examples. = 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 Bruno Busco sent the following on 1/6/2011 2:00 PM: I am sorry, BJ, I do not see your point. What could be the issue? We will have less themes to maintain in the trunk (just Flat Grey, Tomahawk, Default and Multiflex). We will have more people that will be able to maintain additional themes in the Themes Gallery. Production servers will have each one its selected theme (one of the OOTB, one of the Themes Gallery or a customized version of them). -Bruno 2011/1/6 BJ Freemanbjf...@free-man.net how about those that are using ofbiz for SAS and will have many themes for their clients. Bruno Busco sent the following on 1/6/2011 12:51 PM: Yes, having more than one theme in the trunk was originally accepted in order to use and show the visual theme selection feature OOTB. Actually Bluelight, Dropping Crumbs and Tomahawk are one the evolution of the other. Each time we decided to create a new theme instead of replacing the one existing just to avoid problems to users. My proposal is to remove Bluelight, Dropping Crumbs and BizznessTime from the trunk and put them in a separate themes repository as suggested by Ryan. Remove the actual version of the Flat Grey from the trunk and put it in the themes repository. Improve the Flat Grey theme in the trunk with the work you guys are doing. In this way we will have in the trunk two themes for the backend (Actual FlatGrey and Tomahawk) and two themes for the ecommerce (Default and Multiflex). In the themes repository there will be Bluelight, Dropping Crumbs, BizznessTime and the actual FlatGrey. It could be a nice start for the theme repository (and gallery) start. -Bruno 2011/1/6 Jacques Le Rouxjacques.le.r...@les7arts.com Ryan Foster wrote: inline... Ryan L. Foster 801.671.0769 cont...@ryanlfoster.com On Jan 6, 2011, at 11:38 AM, Jacques Le Roux wrote: Ryan Foster wrote: Jacques, I understand your concerns about support, and your thoughts on the themes has some valid points. However, in regards to the BizznessTime theme, I never really intended for that to be my theme anyway. I always viewed it as a community theme as that was it's original intent and it was truly a collaborative effort to build it between myself, my colleagues at HotWax, BrainFood, and other members of the the OFBiz community. Right, sorry for that Ryan. It's only because I know you were one of the fathers (the most important I guess) and helped much at the beginning, my apologies. At any rate, my time issues and focus have shifted significantly over the last few months as I have left HotWax and gone into independent consulting and freelance development. I plan on taking a much more active role in the community in the months and years ahead. That's really a good, very good news! As far as theme contributions go, I wonder if maybe it would be a good idea to have a theme repo outside of the trunk that individuals could commit to? The problem with theme maintenance once a new theme has been added to the trunk is that not everyone has commit privileges to the trunk. This makes the process of maintenance a lot more time consuming for individual contributors as they have to rely on patches, updates, collaboration, etc, rather than just monitoring and maintaining their own code. This could certainly be discussed as themes are no blocking parts as long as *at least one works perfectly* (another way is to become committer), opinions? I think the way that Magento and Wordpress do it are good examples. With Wordpress, there is one official theme that is included with the install, but there are literally thousands of themes that are not maintained by Wordpress that they list on there site http://wordpress.org/extend/themes/, and now with the 3.0 release you can even search for new themes and install them automatically from inside your Wordpress install
[jira] Created: (OFBIZ-4080) Implement a Column Widget
Implement a Column Widget - Key: OFBIZ-4080 URL: https://issues.apache.org/jira/browse/OFBIZ-4080 Project: OFBiz Issue Type: Wish Components: framework Reporter: Bruno Busco Priority: Minor Some time ago there was a discussion on the dev mailing list about how to implement something to display contents in columns on screens. I cut and past an Adrian's idea that is something we should consider to implement. -- From the screen widget XML perspective, it could look like this: column-container column name=first-column !-- column contents -- /column column name=second-column !-- column contents -- /column ... /column-container The column elements can contain additional column-container elements. The column element can have an attribute to specify its width as a percentage of the column-container width. Pixel widths should be avoided since the screen widgets are supposed to be rendering device agnostic. The column-container and column elements will support the common screen widget attributes like name, style, id, etc. The column-container could support a type attribute that controls how the contained columns behave. For example, type=splitter will render the contained columns as a splitter window. From the widget model perspective, the column-container manages resizing columns when one of them is collapsed or its width changes. Column size information needs to be kept in the rendering context. The information would start off with some default values that are overridden by user preferences. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4081) Form widget improvements
Form widget improvements Key: OFBIZ-4081 URL: https://issues.apache.org/jira/browse/OFBIZ-4081 Project: OFBiz Issue Type: Improvement Components: framework Reporter: Bruno Busco Priority: Minor I have a list of ideas about improvements that could be done on the frame widget. I think that creating jiras for these could be a good starting point to discuss, and eventually design and implement them. This issue is an umbrella task for them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4082) Adding a Print this form icon to the top frame bar
Adding a Print this form icon to the top frame bar Key: OFBIZ-4082 URL: https://issues.apache.org/jira/browse/OFBIZ-4082 Project: OFBiz Issue Type: Improvement Reporter: Bruno Busco There should be a new frame tag attribute that would specify that a Print this form icon should be displayed in the top frame bar. This icon should allow the user to print the actual frame in a consistent way (all frame will have the same icon). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4083) Adding a Go to next record and a Go to previous record icons in the frame top bar
Adding a Go to next record and a Go to previous record icons in the frame top bar - Key: OFBIZ-4083 URL: https://issues.apache.org/jira/browse/OFBIZ-4083 Project: OFBiz Issue Type: Improvement Components: framework Reporter: Bruno Busco Priority: Minor These icons should allow to navigate through all the records of a list. These should only be available for single type forms. The list to navigate should be for example the list of records that has been selected by a previous find operation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4084) Adding a Return to search icon in the single frame top bar
Adding a Return to search icon in the single frame top bar Key: OFBIZ-4084 URL: https://issues.apache.org/jira/browse/OFBIZ-4084 Project: OFBiz Issue Type: Improvement Components: framework Reporter: Bruno Busco Priority: Minor If the single frame being displyied comes from a previous search this button icon should allow to go back to the previous search query. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4085) Adding a View attachments button icon to the single form's top bar
Adding a View attachments button icon to the single form's top bar Key: OFBIZ-4085 URL: https://issues.apache.org/jira/browse/OFBIZ-4085 Project: OFBiz Issue Type: Improvement Components: framework Reporter: Bruno Busco Priority: Minor There should be a standard way to allow the display of a list of attachments to a single record. The Attachments icon button with the relative attachments list screen should be a standard feature that should be easily implemented on any single frame record. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4080) Implement a Column Widget
[ https://issues.apache.org/jira/browse/OFBIZ-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco updated OFBIZ-4080: --- Issue Type: Sub-task (was: Wish) Parent: OFBIZ-4081 Implement a Column Widget - Key: OFBIZ-4080 URL: https://issues.apache.org/jira/browse/OFBIZ-4080 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Bruno Busco Priority: Minor Some time ago there was a discussion on the dev mailing list about how to implement something to display contents in columns on screens. I cut and past an Adrian's idea that is something we should consider to implement. -- From the screen widget XML perspective, it could look like this: column-container column name=first-column !-- column contents -- /column column name=second-column !-- column contents -- /column ... /column-container The column elements can contain additional column-container elements. The column element can have an attribute to specify its width as a percentage of the column-container width. Pixel widths should be avoided since the screen widgets are supposed to be rendering device agnostic. The column-container and column elements will support the common screen widget attributes like name, style, id, etc. The column-container could support a type attribute that controls how the contained columns behave. For example, type=splitter will render the contained columns as a splitter window. From the widget model perspective, the column-container manages resizing columns when one of them is collapsed or its width changes. Column size information needs to be kept in the rendering context. The information would start off with some default values that are overridden by user preferences. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4083) Adding a Go to next record and a Go to previous record icons in the frame top bar
[ https://issues.apache.org/jira/browse/OFBIZ-4083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco updated OFBIZ-4083: --- Issue Type: Sub-task (was: Improvement) Parent: OFBIZ-4081 Adding a Go to next record and a Go to previous record icons in the frame top bar - Key: OFBIZ-4083 URL: https://issues.apache.org/jira/browse/OFBIZ-4083 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Bruno Busco Priority: Minor These icons should allow to navigate through all the records of a list. These should only be available for single type forms. The list to navigate should be for example the list of records that has been selected by a previous find operation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4084) Adding a Return to search icon in the single frame top bar
[ https://issues.apache.org/jira/browse/OFBIZ-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco updated OFBIZ-4084: --- Issue Type: Sub-task (was: Improvement) Parent: OFBIZ-4081 Adding a Return to search icon in the single frame top bar Key: OFBIZ-4084 URL: https://issues.apache.org/jira/browse/OFBIZ-4084 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Bruno Busco Priority: Minor If the single frame being displyied comes from a previous search this button icon should allow to go back to the previous search query. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4085) Adding a View attachments button icon to the single form's top bar
[ https://issues.apache.org/jira/browse/OFBIZ-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco updated OFBIZ-4085: --- Issue Type: Sub-task (was: Improvement) Parent: OFBIZ-4081 Adding a View attachments button icon to the single form's top bar Key: OFBIZ-4085 URL: https://issues.apache.org/jira/browse/OFBIZ-4085 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Bruno Busco Priority: Minor There should be a standard way to allow the display of a list of attachments to a single record. The Attachments icon button with the relative attachments list screen should be a standard feature that should be easily implemented on any single frame record. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4021) Adding columns filtering fields in form widget
[ https://issues.apache.org/jira/browse/OFBIZ-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco updated OFBIZ-4021: --- Issue Type: Sub-task (was: New Feature) Parent: OFBIZ-4081 Adding columns filtering fields in form widget -- Key: OFBIZ-4021 URL: https://issues.apache.org/jira/browse/OFBIZ-4021 Project: OFBiz Issue Type: Sub-task 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.
[jira] Created: (OFBIZ-4086) Adding a download CSV file button icon for list forms
Adding a download CSV file button icon for list forms - Key: OFBIZ-4086 URL: https://issues.apache.org/jira/browse/OFBIZ-4086 Project: OFBiz Issue Type: Sub-task Reporter: Bruno Busco -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4086) Adding a download CSV file button icon for list forms
[ https://issues.apache.org/jira/browse/OFBIZ-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12975775#action_12975775 ] Bruno Busco commented on OFBIZ-4086: From the DEV ML 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 Adding a download CSV file button icon for list forms - Key: OFBIZ-4086 URL: https://issues.apache.org/jira/browse/OFBIZ-4086 Project: OFBiz Issue Type: Sub-task Reporter: Bruno Busco -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4011) Implement saved searches and other persisted requests
[ https://issues.apache.org/jira/browse/OFBIZ-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco updated OFBIZ-4011: --- Issue Type: Sub-task (was: New Feature) Parent: OFBIZ-4081 Implement saved searches and other persisted requests - Key: OFBIZ-4011 URL: https://issues.apache.org/jira/browse/OFBIZ-4011 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: SVN trunk Reporter: Scott Gray Priority: Minor Attachments: saved-search.patch https://cwiki.apache.org/confluence/display/OFBIZ/Saved+Searches -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4080) Implement a Column Widget
[ https://issues.apache.org/jira/browse/OFBIZ-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12975777#action_12975777 ] Bruno Busco commented on OFBIZ-4080: This is not strictly related to the frame widget but to the screen one. In any case it could be useful to have it in the frame widget also to replace the actual position attribute for fields. Implement a Column Widget - Key: OFBIZ-4080 URL: https://issues.apache.org/jira/browse/OFBIZ-4080 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Bruno Busco Priority: Minor Some time ago there was a discussion on the dev mailing list about how to implement something to display contents in columns on screens. I cut and past an Adrian's idea that is something we should consider to implement. -- From the screen widget XML perspective, it could look like this: column-container column name=first-column !-- column contents -- /column column name=second-column !-- column contents -- /column ... /column-container The column elements can contain additional column-container elements. The column element can have an attribute to specify its width as a percentage of the column-container width. Pixel widths should be avoided since the screen widgets are supposed to be rendering device agnostic. The column-container and column elements will support the common screen widget attributes like name, style, id, etc. The column-container could support a type attribute that controls how the contained columns behave. For example, type=splitter will render the contained columns as a splitter window. From the widget model perspective, the column-container manages resizing columns when one of them is collapsed or its width changes. Column size information needs to be kept in the rendering context. The information would start off with some default values that are overridden by user preferences. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Create/New Terminology Best Practice
...and even Create New [Artifact] !!! :-) My proposal is to use New [Artifact] everywhere. I faced the same issue with the create buttons. I changed many of them using the New [Artifact] pattern. This is why now I suggest to use the same for the title. Thank you, Bruno 2010/12/22 Adrian Crum adri...@hlmksw.com The OFBiz UI is very inconsistent in the terminology for creating something new - for example creating a new order, a new fixed asset, a new party, etc. Some screens are titled New [Artifact], others are titled Create [Artifact], and lately Edit [Artifact]. Can we agree on one term and add it to the UI Best Practices? -Adrian
Re: Framework Independence
Hi Adrian, did you look into portla-controller.xml ? I used several save-last-view there. -Bruno 2010/12/21 Adrian Crum adri...@hlmksw.com I am nearly finished with the security UI artifacts move. I have one issue preventing me from finishing it and I need some help from the community. The updated code has Party Manager reusing security screens and forms from the common component. It all works great with a few exceptions. The user login screenlet in the View Profile page has links to special screens for adding/editing user logins and assigning user logins to security groups. The forms in those screens are from the common component and they call shared security events - so the user is returned to the shared security screen and not the Party Manager special screen. I need a way to dynamically define the success response view on an event. To illustrate, this request: request-map uri=ProfileEditUserLogin security https=true auth=true/ response name=success type=view value=ProfileEditUserLogin/ /request-map will invoke this event when the user clicks Save: request-map uri=updateUserLoginSecurity security https=true auth=true/ event type=service path= invoke=updateUserLoginSecurity/ response name=success type=view value=EditUserLogin/ response name=error type=view value=EditUserLogin/ /request-map because Party Manager shares a security-related controller XML file and screen widgets. I need the updateUserLoginSecurity event to return to the ProfileEditUserLogin screen instead of EditUserLogin - but without changing the shared updateUserLoginSecurity request-map. I thought I could use the view-save and view-last stuff, but I can't find any documentation on how it works. I tried using it based on existing code but I'm not having any success. Any ideas? -Adrian On 12/18/2010 7:18 AM, Adrian Crum wrote: I will be working on that today. -Adrian --- On Sat, 12/18/10, Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com wrote: IMO the best way to go at this point is to move the ui for the administration of user logins and permissions from the party to the webtools web application. In this way, in a framework only setup, we will have some screens to create new user accounts and administer them. I don't think that we have to provide screens addressed to users (not administrators) to manage their user preferences: the nature of this ui would be too much dependent on the nature of the custom applications that will be used with the framework. Kind regards, Jacopo On Dec 18, 2010, at 3:23 PM, Bruno Busco wrote: By clicking on the party's name in the header the user is directed to this screen: https://demo-trunk.ofbiz.apache.org/partymgr/control/viewprofile?partyId=admin Here there are lots of links and information related to all kind of things: orders, invoices, visits etc. In a framework-only installation this screen should only allow the user to access to its personal information, password, preferences etc. How could we get this? Could we replace this screen with a (non user-editable) PortalPage where every installed application could add their screenlets? Thank you, Bruno 2010/12/16 David E Jonesd...@me.com Not really BJ, there is a consensus on making the framework more (or totally) independent from the applications and specialpurpose components. The only question is the best way to do that, and it looks like as far as a general approach goes (moving minimal needed parts from application components to framework components) a fair consensus is being reached quickly. Of course, this is helped by lots of previous discussion on this topic. -David On Dec 15, 2010, at 10:47 AM, BJ Freeman wrote: I don't think you will find a consensus so just need to branch your own frame work as I did. = 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 Adrian Crum sent the following on 12/15/2010 10:40 AM: To clarify, I'm trying to get the components in the framework folder to run by themselves - without the components found in the applications folder. Some of the framework components have UIs. I understand everyone has a different opinion on what constitutes a framework, so I don't want to rehash that discussion. I just want to disable the components in the applications folder and still have OFBiz run. -Adrian On 12/15/2010 10:13 AM, BJ Freeman wrote: first question is should there be any UI activity at the framework level. Should not it just be the support to allow a UI system to put installed. when I mean UI I am talking about any interaction to the user. = BJ Freeman
Re: Marketing campaigns and contact lists
IMO the complete contactlist package should be moved away from the marketing component and put in party. The reason of this is that a contactlist could be used to notify a group of users of something appening in ANY application. This could be also considered for the framework-only installation. What do you think about? Regards, Bruno 2010/12/14 BJ Freeman bjf...@free-man.net Contact list can be used for many operations. with a many to many relationship then it is achieved with out extra entities. Unless you are adding other fields then there maybe a reason. the model from the data model book is to use enumeration and types to define extra info. just sharing, not against you doing it that way. = 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 Ean Schuessler sent the following on 12/13/2010 4:10 PM: 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.
Re: Marketing campaigns and contact lists
Sure, we could move the whole staff, after the patch is committed. Regards, Bruno 2010/12/18 Hans Bakker mailingl...@antwebsystems.com That is fine if you let me commit the contactlist upgrades from chattree this week...? On Sat, 2010-12-18 at 10:31 +0100, Bruno Busco wrote: IMO the complete contactlist package should be moved away from the marketing component and put in party. The reason of this is that a contactlist could be used to notify a group of users of something appening in ANY application. This could be also considered for the framework-only installation. What do you think about? Regards, Bruno 2010/12/14 BJ Freeman bjf...@free-man.net Contact list can be used for many operations. with a many to many relationship then it is achieved with out extra entities. Unless you are adding other fields then there maybe a reason. the model from the data model book is to use enumeration and types to define extra info. just sharing, not against you doing it that way. = 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 Ean Schuessler sent the following on 12/13/2010 4:10 PM: 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. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com http://twitter.com/hansbak%0AAntwebsystems.com: Quality services for competitive rates.
Re: Marketing campaigns and contact lists
Yes BJ, putting it in the framework instead of party was next option. This can be considered now that also Adrian is trying to split party and move some of it in common (at least I understood this was his idea). -Bruno 2010/12/18 BJ Freeman bjf...@free-man.net +1 for party not sure framework needs the contactlist to operate but considering the pattern of putting things in common that is a possibility. if put in framework a text readme should include where it was put for those that may look for it in party. = 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 Bruno Busco sent the following on 12/18/2010 1:31 AM: IMO the complete contactlist package should be moved away from the marketing component and put in party. The reason of this is that a contactlist could be used to notify a group of users of something appening in ANY application. This could be also considered for the framework-only installation. What do you think about? Regards, Bruno 2010/12/14 BJ Freemanbjf...@free-man.net Contact list can be used for many operations. with a many to many relationship then it is achieved with out extra entities. Unless you are adding other fields then there maybe a reason. the model from the data model book is to use enumeration and types to define extra info. just sharing, not against you doing it that way. = 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 Ean Schuessler sent the following on 12/13/2010 4:10 PM: 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.
[jira] Commented: (OFBIZ-4062) Fix Portal Drag'n'Drop
[ https://issues.apache.org/jira/browse/OFBIZ-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12972790#action_12972790 ] Bruno Busco commented on OFBIZ-4062: This is a minor comment but please use two spaces indentation for .ftl files and not four. Fix Portal Drag'n'Drop -- Key: OFBIZ-4062 URL: https://issues.apache.org/jira/browse/OFBIZ-4062 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/myportal Affects Versions: SVN trunk Reporter: Sascha Rodekamp Assignee: Erwan de FERRIERES Fix For: SVN trunk Attachments: OFBIZ-4062_FixPortalDragnDrop.patch Hi, during the last works on the my portal module, the Drag'n'Drop functionality was lost. Here is a fix which enables the Drag'n'Drop again. Have a goody day Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Framework Independence
By clicking on the party's name in the header the user is directed to this screen: https://demo-trunk.ofbiz.apache.org/partymgr/control/viewprofile?partyId=admin Here there are lots of links and information related to all kind of things: orders, invoices, visits etc. In a framework-only installation this screen should only allow the user to access to its personal information, password, preferences etc. How could we get this? Could we replace this screen with a (non user-editable) PortalPage where every installed application could add their screenlets? Thank you, Bruno 2010/12/16 David E Jones d...@me.com Not really BJ, there is a consensus on making the framework more (or totally) independent from the applications and specialpurpose components. The only question is the best way to do that, and it looks like as far as a general approach goes (moving minimal needed parts from application components to framework components) a fair consensus is being reached quickly. Of course, this is helped by lots of previous discussion on this topic. -David On Dec 15, 2010, at 10:47 AM, BJ Freeman wrote: I don't think you will find a consensus so just need to branch your own frame work as I did. = 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 Adrian Crum sent the following on 12/15/2010 10:40 AM: To clarify, I'm trying to get the components in the framework folder to run by themselves - without the components found in the applications folder. Some of the framework components have UIs. I understand everyone has a different opinion on what constitutes a framework, so I don't want to rehash that discussion. I just want to disable the components in the applications folder and still have OFBiz run. -Adrian On 12/15/2010 10:13 AM, BJ Freeman wrote: first question is should there be any UI activity at the framework level. Should not it just be the support to allow a UI system to put installed. when I mean UI I am talking about any interaction to the user. = 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 Adrian Crum sent the following on 12/15/2010 9:52 AM: I'm working on a project that requires only the OFBiz framework. I'm trying to get a framework-only installation to run. There are a lot of dependencies on the party and content components. Removing dependencies on the party component should be fairly easy. The online help system uses the content component, so that is an issue. Should we move the content component to the framework? -Adrian
Re: Framework Independence
Great! ;-) 2010/12/18 Adrian Crum adrian.c...@yahoo.com I will be working on that today. -Adrian --- On Sat, 12/18/10, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: IMO the best way to go at this point is to move the ui for the administration of user logins and permissions from the party to the webtools web application. In this way, in a framework only setup, we will have some screens to create new user accounts and administer them. I don't think that we have to provide screens addressed to users (not administrators) to manage their user preferences: the nature of this ui would be too much dependent on the nature of the custom applications that will be used with the framework. Kind regards, Jacopo On Dec 18, 2010, at 3:23 PM, Bruno Busco wrote: By clicking on the party's name in the header the user is directed to this screen: https://demo-trunk.ofbiz.apache.org/partymgr/control/viewprofile?partyId=admin Here there are lots of links and information related to all kind of things: orders, invoices, visits etc. In a framework-only installation this screen should only allow the user to access to its personal information, password, preferences etc. How could we get this? Could we replace this screen with a (non user-editable) PortalPage where every installed application could add their screenlets? Thank you, Bruno 2010/12/16 David E Jones d...@me.com Not really BJ, there is a consensus on making the framework more (or totally) independent from the applications and specialpurpose components. The only question is the best way to do that, and it looks like as far as a general approach goes (moving minimal needed parts from application components to framework components) a fair consensus is being reached quickly. Of course, this is helped by lots of previous discussion on this topic. -David On Dec 15, 2010, at 10:47 AM, BJ Freeman wrote: I don't think you will find a consensus so just need to branch your own frame work as I did. = 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 Adrian Crum sent the following on 12/15/2010 10:40 AM: To clarify, I'm trying to get the components in the framework folder to run by themselves - without the components found in the applications folder. Some of the framework components have UIs. I understand everyone has a different opinion on what constitutes a framework, so I don't want to rehash that discussion. I just want to disable the components in the applications folder and still have OFBiz run. -Adrian On 12/15/2010 10:13 AM, BJ Freeman wrote: first question is should there be any UI activity at the framework level. Should not it just be the support to allow a UI system to put installed. when I mean UI I am talking about any interaction to the user. = 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 Adrian Crum sent the following on 12/15/2010 9:52 AM: I'm working on a project that requires only the OFBiz framework. I'm trying to get a framework-only installation to run. There are a lot of dependencies on the party and content components. Removing dependencies on the party component should be fairly easy. The online help system uses the content component, so that is an issue. Should we move the content component to the framework? -Adrian
Re: svn commit: r1049451 - /ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml
Why is this needed for this particular form?
Isn't this automatically managed by the from widget?
-Bruno
2010/12/15 hans...@apache.org
Author: hansbak
Date: Wed Dec 15 08:15:49 2010
New Revision: 1049451
URL: http://svn.apache.org/viewvc?rev=1049451view=rev
Log:
preserve viewindex and size in multipage lists
Modified:
ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml
Modified: ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml?rev=1049451r1=1049450r2=1049451view=diff
==
--- ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml (original)
+++ ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml Wed Dec 15
08:15:49 2010
@@ -355,6 +355,8 @@ under the License.
if(quantity == null || quantity.compareTo(BigDecimal.ZERO)
== 0) quantity = BigDecimal.ONE;
return(quantity.multiply(amount));}/
/row-actions
+ field name=viewSizehidden value=${viewSize}//field
+ field name=viewIndexhidden value=${viewIndex}//field
field name=invoiceIdhidden//field
field name=invoiceItemSeqId widget-style=buttontext
hyperlink target=listInvoiceItems
description=${invoiceItemSeqId}
@@ -384,6 +386,8 @@ under the License.
hyperlink description=${uiLabelMap.CommonRemove}
target=removeInvoiceItem
parameter param-name=invoiceId/
parameter param-name=invoiceItemSeqId/
+parameter param-name=viewIndex/
+parameter param-name=viewSize/
/hyperlink
/field
/form
@@ -467,6 +471,8 @@ under the License.
hyperlink description=${uiLabelMap.CommonRemove}
target=removeInvoiceApplication
parameter param-name=paymentApplicationId/
parameter param-name=invoiceId/
+parameter param-name=viewIndex/
+parameter param-name=viewSize/
/hyperlink
/field
/form
@@ -523,6 +529,8 @@ under the License.
parameter param-name=invoiceId/
parameter param-name=partyId/
parameter param-name=roleTypeId/
+parameter param-name=viewIndex/
+parameter param-name=viewSize/
/hyperlink
/field
/form
Re: svn commit: r1049451 - /ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml
OK, now I better see what you mean.
Thank you,
Bruno
2010/12/15 Hans Bakker mailingl...@antwebsystems.com
As far as i can see it is currently not
if you are on page 2 and press a update/delete button, the system will
show page one again
Regards,
Hans
On Wed, 2010-12-15 at 13:51 +0100, Bruno Busco wrote:
Why is this needed for this particular form?
Isn't this automatically managed by the from widget?
-Bruno
2010/12/15 hans...@apache.org
Author: hansbak
Date: Wed Dec 15 08:15:49 2010
New Revision: 1049451
URL: http://svn.apache.org/viewvc?rev=1049451view=rev
Log:
preserve viewindex and size in multipage lists
Modified:
ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml
Modified: ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml?rev=1049451r1=1049450r2=1049451view=diff
==
--- ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml
(original)
+++ ofbiz/trunk/applications/accounting/widget/InvoiceForms.xml Wed Dec
15
08:15:49 2010
@@ -355,6 +355,8 @@ under the License.
if(quantity == null ||
quantity.compareTo(BigDecimal.ZERO)
== 0) quantity = BigDecimal.ONE;
return(quantity.multiply(amount));}/
/row-actions
+ field name=viewSizehidden value=${viewSize}//field
+ field name=viewIndexhidden value=${viewIndex}//field
field name=invoiceIdhidden//field
field name=invoiceItemSeqId widget-style=buttontext
hyperlink target=listInvoiceItems
description=${invoiceItemSeqId}
@@ -384,6 +386,8 @@ under the License.
hyperlink description=${uiLabelMap.CommonRemove}
target=removeInvoiceItem
parameter param-name=invoiceId/
parameter param-name=invoiceItemSeqId/
+parameter param-name=viewIndex/
+parameter param-name=viewSize/
/hyperlink
/field
/form
@@ -467,6 +471,8 @@ under the License.
hyperlink description=${uiLabelMap.CommonRemove}
target=removeInvoiceApplication
parameter param-name=paymentApplicationId/
parameter param-name=invoiceId/
+parameter param-name=viewIndex/
+parameter param-name=viewSize/
/hyperlink
/field
/form
@@ -523,6 +529,8 @@ under the License.
parameter param-name=invoiceId/
parameter param-name=partyId/
parameter param-name=roleTypeId/
+parameter param-name=viewIndex/
+parameter param-name=viewSize/
/hyperlink
/field
/form
--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com http://twitter.com/hansbak%0AAntwebsystems.com:
Quality services for competitive rates.
Re: svn commit: r1045337 - /ofbiz/trunk/framework/widget/dtd/widget-screen.xsd
Could we use perhaps some xs:pattern ? 2010/12/14 Erwan de FERRIERES erwan.de-ferrie...@nereide.fr Le 14/12/2010 09:35, Scott Gray a écrit : On 14/12/2010, at 9:16 PM, Erwan de FERRIERES wrote: Le 14/12/2010 07:37, Bruno Busco a écrit : A variable name as enumeration value? Sorry but I have never seen this pattern. What's different in conf-mode and use-private from all other expandable boolean attributes? -Bruno Hi Bruno and Scott, Ok, this was not pretty. Those variables were introduced at this rev, could you tell me how to handle it in the DTD ? https://fisheye6.atlassian.com/changelog/ofbiz/?cs=1023286 We have this pattern in a few places so I don't have a problem with that, it's just the parameters map prefix that I hadn't seen before. Regards Scott So, just a revert will be the solution ? My point was just that validation wasn't done because of those parameters. maybe there is something else we can do ? -- Erwan de FERRIERES www.nereide.biz
Re: svn commit: r1045337 - /ofbiz/trunk/framework/widget/dtd/widget-screen.xsd
A variable name as enumeration value?
Sorry but I have never seen this pattern.
What's different in conf-mode and use-private from all other expandable
boolean attributes?
-Bruno
2010/12/13 er...@apache.org
Author: erwan
Date: Mon Dec 13 19:44:54 2010
New Revision: 1045337
URL: http://svn.apache.org/viewvc?rev=1045337view=rev
Log:
Adding enumerations for the conf-mode and use-private elements. Those are
used for include-portal-page. This way we can use the parameters and the
file is still valid
Modified:
ofbiz/trunk/framework/widget/dtd/widget-screen.xsd
Modified: ofbiz/trunk/framework/widget/dtd/widget-screen.xsd
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/dtd/widget-screen.xsd?rev=1045337r1=1045336r2=1045337view=diff
==
--- ofbiz/trunk/framework/widget/dtd/widget-screen.xsd (original)
+++ ofbiz/trunk/framework/widget/dtd/widget-screen.xsd Mon Dec 13 19:44:54
2010
@@ -1101,6 +1101,7 @@ under the License.
xs:restriction base=xs:token
xs:enumeration value=true/
xs:enumeration value=false/
+xs:enumeration value=${parameters.confMode}/
/xs:restriction
/xs:simpleType
/xs:attribute
@@ -1110,6 +,7 @@ under the License.
xs:restriction base=xs:token
xs:enumeration value=true/
xs:enumeration value=false/
+xs:enumeration value=${parameters.usePrivate}/
/xs:restriction
/xs:simpleType
/xs:attribute
Re: demo server performance
Yesterday I gave a look to the demo visits and found that Google is hitting the server about every 30 seconds. So it is possible that any URL (includind Webtools-Artifact Info) is hitten almost frequently. -Bruno 2010/12/10 Jacques Le Roux jacques.le.r...@les7arts.com From: BJ Freeman bjf...@free-man.net Thanks for you view on my motives. From what Jacques states the server has max hardware resources. so what resources are you referring to? I since I have a similar server running more than what Jacques has stated, and it runs, I am at a loss on how to work on the ofbiz demo. I have been focused as much as I am allowed on this for almost a year. considering posting five urls at the same time should not effect a server, I don't see that as testing the limits of the server. Which URLs? It really depends on them... Artifact Info, Entity Maintenance, Label Manager, etc. are good culprits... This does not mean that we can't use Entity Maintenance on the demo server, nor even Artifact Info. But it depends on the number of people which are using them at the same time. And when it's down, it's down: you will have to wait a good soul (not sleeping, like me in some mins) to reload the demo instance... Webtools are not all days tools for a production server... I will suggest to use rather such tools locally... Does it make sense? Thanks Jacques Scott Gray sent the following on 12/9/2010 1:47 PM: Everybody works on the areas of the system that are important to them, I suggest you do the same. The demo server is under-resourced so of course you're going to be able to bring it down if you try to, my suggestion is that you don't try to. Regards Scott HotWax Media http://www.hotwaxmedia.com On 10/12/2010, at 10:32 AM, BJ Freeman wrote: there is a thread on the user ML about the demo being slow. I would think that would be a high priority for all those that commit and make changes to ofbiz. after all what good is all this stuff if it can't be used. I brought down the demo trunk by accessing with seperate requests at one time, as I stated on the user ml. lets focus on real problems.
Re: demo server performance
Or, maybe those certain things should not be enabled by default. Maybe move them to a specialpurpose location, which then extends the framework/application components with additional menu/screen entries. We could also manage a patch committed to the SVN that is used for the demo server. The patch should be applied on the demo only and disable whatever we like. -Bruno
Re: jquey
Jacques, you have already ported in the jquery branch all the changes of the trunk. So now the jquery branch is actually how the trunk should be after the merge. Any conflict should be quickly resolved using the copy of the files from the jquery brqnch. -Bruno 2010/12/10 Sascha Rodekamp sascha.rodekamp.lynx...@googlemail.com Oh Jacques you have my sympathy svn conflicts in such a merge can really be a pain. But I think you can handle it. Chucka :-) Am 09.12.2010 um 19:35 schrieb Jacques Le Roux jacques.le.r...@les7arts.com: At 1st glance it does not look like a quickly done task. There are 68 conflicts to handle. 70% are tree conflicts, hopefully easier to handle... Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Hi Rohit, As I already said, I hope to do it before the new year... I want at least to fix this before https://issues.apache.org/jira/browse/OFBIZ-4030 Fortunately you may help since it seems the issue is in the trunk, see my comment Also I will need to put a tag before the back merge to trunk. I wonder if we should not avoid to commit between these 2 events. In order to have not changes trapped bewteen, not a big deal if I can do the back merge quickly. So I will try locally before... Thanks Jacques Hi Jacques, I guess everybody has agreed with the merger, so when can we can be expect it to be done. I am sorry if i sound little haste, but we are very eagerly waiting for it. thanks, Rohit - http://www.saanjhi.com saanjhi.com -- View this message in context: http://ofbiz.135035.n4.nabble.com/jquey-tp3068464p3075960.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: jquey
Hi All, I am sorry if my suggestion to create a release branch has delayed somehow the merging of the great work that Jacques and Sasha have done. This was not my intention at all. The idea was just to create a release branch; this, IMO, should not have delayed the merging. The reason of the branch was to offer a place where to live to people that are now using the trunk if any issue with the jQuery should arise, until, thanks to the massive test that will start only now that we will have it in the trunk, will fix everythink. Apart of that I do not see any other issue. So please, go ahead with the merge, do not delay any further. We will handle any issue as they come (if any). Thank you, Bruno 2010/12/5 Scott Gray scott.g...@hotwaxmedia.com Hi Bruno, I guess I missed your original email but what was the reason for creating a new release branch outside of our normal schedule? Personally I don't see any reason why we can't just merge the jquery branch and carry on as normal. If people choose to develop custom projects against the trunk then good for them but I don't think we need to consider that when making decisions on moving the trunk forward. Regards Scott HotWax Media http://www.hotwaxmedia.com On 3/12/2010, at 6:59 PM, 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
[jira] Reopened: (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:all-tabpanel ] Bruno Busco reopened OFBIZ-4037: The commit has been reverted as suggested by Adam. The reason was that the patch adds in the framework several dependencies from the applications (mainly Party). A rework must be done. A possible solution could be to move the register stuff to the commonext component instead of common. What do you think? 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 Assignee: 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.
Re: jquey
+1 ;-) 2010/12/5 Jacques Le Roux jacques.le.r...@les7arts.com Hi Bruno, OK, then a tag should be sufficient. What about beforejQuery? Jacques From: Bruno Busco bruno.bu...@gmail.com Hi All, I am sorry if my suggestion to create a release branch has delayed somehow the merging of the great work that Jacques and Sasha have done. This was not my intention at all. The idea was just to create a release branch; this, IMO, should not have delayed the merging. The reason of the branch was to offer a place where to live to people that are now using the trunk if any issue with the jQuery should arise, until, thanks to the massive test that will start only now that we will have it in the trunk, will fix everythink. Apart of that I do not see any other issue. So please, go ahead with the merge, do not delay any further. We will handle any issue as they come (if any). Thank you, Bruno 2010/12/5 Scott Gray scott.g...@hotwaxmedia.com Hi Bruno, I guess I missed your original email but what was the reason for creating a new release branch outside of our normal schedule? Personally I don't see any reason why we can't just merge the jquery branch and carry on as normal. If people choose to develop custom projects against the trunk then good for them but I don't think we need to consider that when making decisions on moving the trunk forward. Regards Scott HotWax Media http://www.hotwaxmedia.com On 3/12/2010, at 6:59 PM, 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
[jira] Closed: (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:all-tabpanel ] Bruno Busco closed OFBIZ-4037. -- Resolution: Fixed Assignee: Bruno Busco Committed to the trunk At revision: 1042196 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 Assignee: 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.
Re: How to automatically set columns in a list form from a map?
Thank you Jacopo for the insight. I will put this on my list or better I will open a JIRA so that we can remember about this. -Bruno 2010/12/4 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com On Dec 4, 2010, at 12:09 AM, Bruno Busco wrote: 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? It makes a lot of sense to me and it is something I also considered in the past; this could also be used to reimplement with widgets the entity data maintenance screens of the webtools. Implementing this is a bit tricky because the model of a form is loaded (and cached) the first time it is used (i.e. it is assumed to be static) while the new enhancement will make the definition dynamic. Kind regards, Jacopo Thank you, Bruno
Re: REVERT: Re: svn commit: r1042196 - in /ofbiz/trunk: framework/common/config/ framework/common/script/org/ofbiz/common/ framework/common/webcommon/ framework/common/webcommon/WEB-INF/ framework/com
Thank you Adam, I have reverted in revision 1042250. The patch should be further worked before committed again. -Bruno 2010/12/4 Adam Heath doo...@brainfood.com bus...@apache.org wrote: Author: buscob Date: Sat Dec 4 14:58:18 2010 New Revision: 1042196 URL: http://svn.apache.org/viewvc?rev=1042196view=rev Log: https://issues.apache.org/jira/browse/OFBIZ-4037 Moved the feature that allows a new user to register for an account from MyPortal to the framework so that it is available in any application. It has also been slightly reworked (code cleaning and internationalization). Two flags in general.properties allows to configure if the register function must be enabled or not and if the captcha function should be used. The captcha function needs to be improved because at the moment the code is contained in an hidden field so that it is very easy for a computer to bypass it. A possible fix for this could be to put the MD5 coding of the captcha code in the hidden field. Then the event that checks the code should compare the MD5 codes. Added: ofbiz/trunk/framework/common/script/org/ofbiz/common/RegisterEvents.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/script/org/ofbiz/common/RegisterEvents.xml?rev=1042196view=auto == --- ofbiz/trunk/framework/common/script/org/ofbiz/common/RegisterEvents.xml (added) +++ ofbiz/trunk/framework/common/script/org/ofbiz/common/RegisterEvents.xml Sat Dec 4 14:58:18 2010 + +!-- Create E-mail address -- +set field=emailContext.emailAddress from-field=parameters.USER_EMAIL/ +call-service service-name=createPartyEmailAddress in-map-name=emailContext +result-to-field result-name=contactMechId field=emailPurposeContext.contactMechId/ +/call-service I'm sorry, but no. This is code inside framework calling code in applications. There are other examples of this in this patch as well. Please don't do this.
[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.
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 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.
Re: jquey
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: [jira] Closed: (OFBIZ-4006) jQuery Test and Bug fixing
I vote for doing a release branch first and then merge jQuery. This will let people to have a branch with the actual trunk in case the jQuery causes any issues to them. Thank you, Bruno 2010/12/1 Deepak Dixit deepak.di...@hotwaxmedia.com jQuery provide lot of pluginns and good thing is that all of these pluginns are cross browser compatible. So +1 for merge jQuery with trunk and then create release branch with jQuery. Thanks Regards -- Deepak Dixit HotWax Media Pvt. Ltd. Website :- www.hotwaxmedia.com Contact :- +91-98267-54548 Skype Id :- deepakdixit Jacques Le Roux wrote: Other opinions? Jacques From: Bruno Busco bruno.bu...@gmail.com I would prefer to have the release branch before the merge with jQuery. -Bruno 2010/11/27 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com We may want to create a new release branch (before or after the merge with jQuery?) and officially release 10.04. Jacopo On Nov 27, 2010, at 10:57 AM, Jacques Le Roux wrote: Yes, there is no hurry to merge jQuery, and a branch before could be a good idea indeed. This could be an answer for removing or not all Prototype/Dojo from the trunk. With this branch people could rely on it for Prototype/Dojo. Those interested by the trunk are already leaving on the leading-edge and should not worry too much. On the other hand maybe some would prefer to have jQuery in the next release? And also should we wait 11.xx? 11.01 would be okay for me... BTW for those interested please be sure to check this thread (Bilgin noticed that I mixed 2 subjects in it: jQuery docs and demo and removing Prototype/Dojo from the trunk or not) http://markmail.org/message/mpdywy4ymkjddrpr Jacques From: Bruno Busco bruno.bu...@gmail.com What about creating a new release branch before merging the jquery ? -Bruno 2010/11/26 Jacques Le Roux jacques.le.r...@les7arts.com Hi Rohit, Hopefully before new year, but we will need more testing, could you help? Thanks Jacques From: rohit rohitksur...@yahoo.com hi, when can we expect the jQuery branch to be merged with the truck, it that expected at all... thanks rohit -- View this message in context: http://ofbiz.135035.n4.nabble.com/jira-Created-OFBIZ-4006-jQuery-Test-and-Bug-fixing-tp3016706p3060540.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] Commented: (OFBIZ-4036) encode-output does not working for display tag description
[
https://issues.apache.org/jira/browse/OFBIZ-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964545#action_12964545
]
Bruno Busco commented on OFBIZ-4036:
Thank you Scott,
I also backported to R10.4 at revision: 1039878.
encode-output does not working for display tag description
--
Key: OFBIZ-4036
URL: https://issues.apache.org/jira/browse/OFBIZ-4036
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Bruno Busco
Assignee: Scott Gray
Fix For: SVN trunk
I want to show some HTML text in a form field.
I used this code below:
field name=carCount title=${uiLabelMap.FMC_CarCount}
encode-output=false
display description=${carCountLink} /
/field
The carCountLink is a string containing some HTML code.
The HTML code itself is shown in the form field instead of being processed as
HTML and renderd accordingly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-4037) Moving the user SignUp feature from MyPortal to the Framework
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 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] Updated: (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:all-tabpanel ] Bruno Busco updated OFBIZ-4037: --- Attachment: ofbiz_signup.patch 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.
Re: [jira] Closed: (OFBIZ-4006) jQuery Test and Bug fixing
I would prefer to have the release branch before the merge with jQuery. -Bruno 2010/11/27 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com We may want to create a new release branch (before or after the merge with jQuery?) and officially release 10.04. Jacopo On Nov 27, 2010, at 10:57 AM, Jacques Le Roux wrote: Yes, there is no hurry to merge jQuery, and a branch before could be a good idea indeed. This could be an answer for removing or not all Prototype/Dojo from the trunk. With this branch people could rely on it for Prototype/Dojo. Those interested by the trunk are already leaving on the leading-edge and should not worry too much. On the other hand maybe some would prefer to have jQuery in the next release? And also should we wait 11.xx? 11.01 would be okay for me... BTW for those interested please be sure to check this thread (Bilgin noticed that I mixed 2 subjects in it: jQuery docs and demo and removing Prototype/Dojo from the trunk or not) http://markmail.org/message/mpdywy4ymkjddrpr Jacques From: Bruno Busco bruno.bu...@gmail.com What about creating a new release branch before merging the jquery ? -Bruno 2010/11/26 Jacques Le Roux jacques.le.r...@les7arts.com Hi Rohit, Hopefully before new year, but we will need more testing, could you help? Thanks Jacques From: rohit rohitksur...@yahoo.com hi, when can we expect the jQuery branch to be merged with the truck, it that expected at all... thanks rohit -- View this message in context: http://ofbiz.135035.n4.nabble.com/jira-Created-OFBIZ-4006-jQuery-Test-and-Bug-fixing-tp3016706p3060540.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: svn commit: r1039651 [38/38] - in /ofbiz/branches/jquery: ./ applications/accounting/config/ applications/accounting/src/org/ofbiz/accounting/thirdparty/authorizedotnet/ applications/commonext/con
There are some value tags outside of the property tags in this commit.
For instance this below:
@@ -59,16 +65,22 @@
value xml:lang=itCognome mancante/value
value xml:lang=thภรุณาภรà¸à¸ นามสà¸
ุลขà¸à¸‡à¸—่าน/
value
value xml:lang=zhç¼ºå°‘ä½ çš„å§“/value
+value xml:lang=zh_TWç¼ºå°‘å§“æ° (Lastname)/value
/property
property key=MyPortalMyOrders
value xml:lang=enMy Orders/value
+value xml:lang=zh_TW我的訂單/value
/property
+value xml:lang=zh_TW我的任務/value
+value xml:lang=zh_TW我的時間/value
+value xml:lang=zh_TWæ–°çš„è¨Šæ ¯/value
property key=MyPortalNewRegistration
value xml:lang=enNew Registration /value
value xml:lang=frNouvel enregistrement/value
value xml:lang=itNuovo utente/value
value xml:lang=thลงทะเบียน /value
value xml:lang=zh新注册/value
+value xml:lang=zh_TW新的註冊/value
/property
property key=MyPortalPicCaptcha
value xml:lang=enCode Captcha/value
2010/11/27 jler...@apache.org
Modified:
ofbiz/branches/jquery/specialpurpose/ecommerce/webapp/ecommerce/customer/messagelist.ftl
URL:
http://svn.apache.org/viewvc/ofbiz/branches/jquery/specialpurpose/ecommerce/webapp/ecommerce/customer/messagelist.ftl?rev=1039651r1=1039650r2=1039651view=diff
==
---
ofbiz/branches/jquery/specialpurpose/ecommerce/webapp/ecommerce/customer/messagelist.ftl
(original)
+++
ofbiz/branches/jquery/specialpurpose/ecommerce/webapp/ecommerce/customer/messagelist.ftl
Sat Nov 27 10:59:21 2010
@@ -17,7 +17,7 @@ specific language governing permissions
under the License.
--
-#macro showMessage communicationEvent isSentMessage
+#macro showMessage communicationEvent isSentMessage index
#if communicationEvent.partyIdFrom?has_content
#assign partyNameFrom =
Static[org.ofbiz.party.party.PartyHelper].getPartyName(delegator,
communicationEvent.partyIdFrom, true)
#else/
@@ -34,12 +34,16 @@ under the License.
tddiv
class=tabletext${communicationEvent.subject?default()}/div/td
tddiv
class=tabletext${communicationEvent.entryDate}/div/td
td align=right
- form method=post
action=@ofbizUrlreadmessage/@ofbizUrl name=ecomm_read_mess
+ form method=post
action=@ofbizUrlreadmessage/@ofbizUrl name=ecomm_read_mess${index}
input name=communicationEventId
value=${communicationEvent.communicationEventId} type=hidden/
/form
- a
href=javascript:document.ecomm_read_mess.submit()${uiLabelMap.EcommerceRead}/a
+ a
href=javascript:document.ecomm_read_mess${index}.submit()${uiLabelMap.EcommerceRead}/a
+
#if isSentMessage
-a
href=@ofbizUrlnewmessage?communicationEventId=${communicationEvent.communicationEventId}/@ofbizUrl
class=buttontext${uiLabelMap.PartyReply}/a
+ form method=post
action=@ofbizUrlnewmessage/@ofbizUrl name=ecomm_sent_mess${index}
+input name=communicationEventId
value=${communicationEvent.communicationEventId} type=hidden/
+ /form
+ a
href=javascript:document.ecomm_sent_mess${index}.submit()${uiLabelMap.PartyReply}/a
/#if
/td
/tr
@@ -70,10 +74,10 @@ under the License.
/tr
trtd colspan=5hr //td/tr
#list receivedCommunicationEvents?if_exists as
receivedCommunicationEvent
- @showMessage communicationEvent=receivedCommunicationEvent
isSentMessage=false/
+ @showMessage communicationEvent=receivedCommunicationEvent
isSentMessage=false index=receivedCommunicationEvent_index/
/#list
#list sentCommunicationEvents?if_exists as
sentCommunicationEvent
- @showMessage communicationEvent=sentCommunicationEvent
isSentMessage=true/
+ @showMessage communicationEvent=sentCommunicationEvent
isSentMessage=true index=sentCommunicationEvent_index/
/#list
/#if
/table
Propchange:
ofbiz/branches/jquery/specialpurpose/hhfacility/webapp/hhfacility/WEB-INF/actions/Facilities.groovy
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Sat Nov 27 10:59:21 2010
@@ -1,3 +1,3 @@
/incubator/ofbiz/trunk/specialpurpose/hhfacility/webapp/hhfacility/WEB-INF/actions/Facilities.groovy:418499-490456
/ofbiz/branches/multitenant20100310/specialpurpose/hhfacility/webapp/hhfacility/WEB-INF/actions/Facilities.groovy:921280-927264
-/ofbiz/trunk/specialpurpose/hhfacility/webapp/hhfacility/WEB-INF/actions/Facilities.groovy:951708-1036339
