Re: Discussion: Support Screen Widget Namespaces
I've been playing around with Jelly (http://commons.apache.org/jelly/) lately and it might be worth taking a look at while you're on this train of thought. Regards Scott HotWax Media http://www.hotwaxmedia.com On 2/01/2011, at 8:14 PM, Adrian Crum wrote: I've tried several ideas to make UI coding easier, one of them being a Groovy screen renderer - where you can mix scripting code with markup. That idea was very close to JSP, and I don't like JSP because I don't like the spaghetti-like mess you end up with when the boundaries between data preparation and presentation are removed. On the opposite end of the pendulum are the screen widgets - where the boundaries are a little too strict, and sometimes they are an obstacle to getting things done. I've come up with workarounds. One of them was in the example code I supplied in a recent commit message - where I use a screen widget for nothing more than a small reusable script. That's when I came up with this idea, and I believe it is a good compromise. You have good separation of concerns, but you also have the convenience of all of it being in one file. I noticed you've been hard at work on Moqui. It looks like you have a lot of work ahead of you. I'm looking forward to seeing it when it's done. -Adrian --- On Sat, 1/1/11, David E Jones d...@me.com wrote: I agree, bouncing around between a lot of files is a pain, as is having certain files get really large (like the controller.xml file). Working with apps I always have at least a controller.xml file, entitymodel.xml file, one or more services.xml files, one or more simple-method and/or java files, one or more screens.xml files, one or more forms.xml files, occasionally a menus.xml file, a UiLabels.xml file, one or more Data.xml files, and a (insert favorite euphemism here; partridge in a pear tree or kitchen sink are possibilities). I say I don't know if this is a good idea, but it might end up being quite helpful even with the way things are defined separately in OFBiz. In Moqui I went a different direction and there is no controller.xml file, everything there is in the screen definition. Also, the forms and other widgets are not separate and they are just other widgets built into the screen (though forms still have names and are can be referred to from other screens). So, anyway, what you propose might be a good step in that direction without requiring a huge rewrite (like Moqui is... and I'm feeling the pain of it now that I've moved from design to implementation!). -David On Jan 1, 2011, at 3:35 PM, Adrian Crum wrote: Here's the Jira issue: https://issues.apache.org/jira/browse/OFBIZ-4090 I agree that this feature could be abused. It's another choice a developer can make. The project I'm working on right now could benefit from this - I spend way too much time bouncing from file to file while working on a single screen. In this case, the separate files are a drawback - not an advantage. -Adrian --- On Sat, 1/1/11, David E Jones d...@me.com wrote: From: David E Jones d...@me.com Subject: Re: Discussion: Support Screen Widget Namespaces To: dev@ofbiz.apache.org Date: Saturday, January 1, 2011, 3:20 PM Another approach might be to create a schema that represents the combined schemas of all three and just include the other XSD files using something like: xs:include schemaLocation=widget-screen.xsd/ As long as they are all in the same directory this should work fine. You'll probably need to give it a new root element that allows all of the different screen, form, etc sub-elements to make it useful. Chances are you'll run into conflicting element names too. The widgets should have been done this way from the beginning, ie using various includes, so that things like the actions element could be defined in one place and shared between all of the different types of widgets, instead of having small variations between each (which developed by lack of checking for consistency). BTW, I'm not sure if putting different types of widgets or other things in the same file is a good idea (I guess only time can tell), but it should be possible. -David On Jan 1, 2011, at 3:10 PM, Adrian Crum wrote: It's not an issue of conflicting element names. It's an issue because all of the widget XML files expect to have only one schema. If you have screens, forms, and menus all in one file, then you need to support multiple schemas. I have it basically working - I just need to figure out a validation error. The existing schemas don't have a TargetNamespace defined, which causes an error. If I add a TargetNamespace, then I get a different error saying it was expecting it to be empty. ::scratches head:: I'll post a patch on Jira, maybe an XML expert can figure it out. -Adrian --- On Sat, 1/1/11, David E Jones d...@me.com wrote: From: David E Jones
Re: Discussion: Flat Grey Visual Theme
I really would appreciate to keep the Flat Gray. But you're right it needs a few visual improvements. Let me think about this, maybe somethink comes to my mind . :-) Cheers 2010/12/29 Jacques Le Roux jacques.le.r...@les7arts.com IIRW, it's the only really RTL capable. So a big YES to keep it, of course. I have no ideas though :/ Jacques From: Adrian Crum adrian.c...@yahoo.com The Flat Grey visual theme is getting old. The current version of the theme is based on the original look and feel of OFBiz when I first joined the community - back in 2004. Around the Spring of 2007 I added some gradient gifs to make the original style a little more interesting. After that, the visual theme was converted to a floating flexible layout (to fit any size screen), it was made sight-impaired accessible (font size can be changed), and it added support for bi-directional layout (for rtl languages). Those design decisions were made by the OFBiz community and, in my opinion, continue to make the Flat Grey theme the fallback theme when all else fails. It just works. Despite its advantages, it looks dated. I would like to update it to make it more modern, but maintain its advantages over the other themes. I'm thinking it only needs css and gif file updates. The current templates and javascripts would be maintained. If anyone is interested, they are welcome to help out. I would also appreciate any suggestions or comments. Let me know what you think. -Adrian -- Sascha Rodekamp Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de
[jira] Closed: (OFBIZ-4088) DHL use the new Shipment Gateway Config features
[ https://issues.apache.org/jira/browse/OFBIZ-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Risaliti closed OFBIZ-4088. - Resolution: Fixed Fix Version/s: SVN trunk Fixed into trunk rev. 1054389. Marco DHL use the new Shipment Gateway Config features Key: OFBIZ-4088 URL: https://issues.apache.org/jira/browse/OFBIZ-4088 Project: OFBiz Issue Type: Sub-task Reporter: Marco Risaliti Assignee: Marco Risaliti Fix For: SVN trunk Attachments: dhl.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-4089) USPS use the new Shipment Gateway Config features
[ https://issues.apache.org/jira/browse/OFBIZ-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Risaliti updated OFBIZ-4089: -- Attachment: usps.patch First patch USPS use the new Shipment Gateway Config features - Key: OFBIZ-4089 URL: https://issues.apache.org/jira/browse/OFBIZ-4089 Project: OFBiz Issue Type: Sub-task Reporter: Marco Risaliti Assignee: Marco Risaliti Attachments: usps.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-4089) USPS use the new Shipment Gateway Config features
[ https://issues.apache.org/jira/browse/OFBIZ-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Risaliti closed OFBIZ-4089. - Resolution: Fixed Fix Version/s: SVN trunk Fixed into trunk rev. 1054435 USPS use the new Shipment Gateway Config features - Key: OFBIZ-4089 URL: https://issues.apache.org/jira/browse/OFBIZ-4089 Project: OFBiz Issue Type: Sub-task Reporter: Marco Risaliti Assignee: Marco Risaliti Fix For: SVN trunk Attachments: usps.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-2589) New Shipment Gateway Config entities
[ https://issues.apache.org/jira/browse/OFBIZ-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Risaliti closed OFBIZ-2589. - Resolution: Fixed Now that all the shipment gateway supports the new Config entities I could close the main issue. Thanks Marco New Shipment Gateway Config entities Key: OFBIZ-2589 URL: https://issues.apache.org/jira/browse/OFBIZ-2589 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: SVN trunk Reporter: Marco Risaliti Assignee: Marco Risaliti Priority: Minor Fix For: SVN trunk Attachments: ShipmentGatewayConfig.patch, ShipmentGatewayConfig2.patch Add some new entities/fields to move the shipment gateway config from shipment.properties to the new entities. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Discussion: Support Screen Widget Namespaces
--- On Sat, 1/1/11, David E Jones d...@me.com wrote: In Moqui I went a different direction and there is no controller.xml file, everything there is in the screen definition. We could do that in OFBiz too. Since the controller.xml file supports the include element, it would be a simple matter to add a controller element to the compound screen widget file, and then use the controller's include element to include the compound screen widget file. The more I think about it, the more I like the idea. -Adrian
Re: Discussion: Compound Screen Widget Files (was: Discussion: Support Screen Widget Namespaces)
In case anyone is wondering what the advantage is to doing things this way, I can use the Party Manager as an example. The Party Manager application is huge. For the most part, having all screens in one file, all forms in one file, all menus in one file, etc makes sense. But in an application that size, those files have become very big and monolithic. That slows down development because a lot of time is spent going from file to file and searching through the file for the bit of information you need. There are portions of the Party Manager application that are somewhat atomic and lend themselves well to being separated out. Let's use the Party Roles screen as an example. The Party Roles screen contains 1 screen widget (not including the decorators), and 4 form widgets. The screen widget is defined in PartyScreens.xml - which contains about 35 screen widgets. The form widgets are defined in PartyForms.xml - which contains around 50 form widgets. We *could* put those 4 form widgets in their own form widget file, but then we would still have an additional file to work with. The Party Roles screen requires 4 requests and 1 view map. Those requests and view map are in the controller.xml file - which is 1338 lines long. Again, we *could* put those requests and view in a separate file, but then we would still have an additional file to work with. Here is how the Party Roles screen artifacts could be organized in the proposed compound widget file: We could create a file called PartyRole.xml, and then put the 1 screen widget, 4 form widgets, 4 requests, and 1 view map in that file. All Party Role UI-related artifacts are now in one place where they are easy to find. The same process could be repeated for Party Relationships. -Adrian --- On Sun, 1/2/11, Adrian Crum adrian.c...@yahoo.com wrote: Okay, I got the XML parsing errors fixed. It required new schemas. If we want to add this feature to the project, we will need two versions of some schemas (all screen widget xsd files, simple-methods.xsd and site-conf.xsd). The new versions could include a version number in the file name, like widget-screen-v2.xsd as an example. Adding the version number to the xsd file name also solves another problem - currently all versions of OFBiz are referencing a single xsd file version. In the future, as xsd files are changed, they could be given a new version number and the dependent XML files would be updated to reference them. Or we could have the version number in the url and put the new schemas in the new url. David suggested using schema includes to share schemas (like for widget actions). This change could be a first step in that direction - because the new schemas will have their own namespace. I have updated the Jira issue with a new patch so everyone can take a look: https://issues.apache.org/jira/browse/OFBIZ-4090 Comments and suggestions are welcome! -Adrian --- On Sun, 1/2/11, Adrian Crum adrian.c...@yahoo.com wrote: --- On Sat, 1/1/11, David E Jones d...@me.com wrote: In Moqui I went a different direction and there is no controller.xml file, everything there is in the screen definition. We could do that in OFBiz too. Since the controller.xml file supports the include element, it would be a simple matter to add a controller element to the compound screen widget file, and then use the controller's include element to include the compound screen widget file. The more I think about it, the more I like the idea.
