Thanks Scott, I agree. We need to use flexible and generic tools like CSS more, and stop creating so many nightmares of parameterization. It seems like over the last few years every new general feature has been handled not by design and considering the best generic solution, or by looking at where the framework can be extended or changed to handle something better (while keeping things like visual elements separated from business and technical elements, ie the form widget ideally shouldn't have ANY styling in it and even layout is separated from the base field definitions). It seems like all of the new features are handled by parameterizing the heck out of default templates and creating decorator screens and all sorts of inconsistent "conventions".
This maybe goes back to the the discussion in the "hiding functionality in ofbiz." thread. It's pretty clear that a big problem is near zero collaboration on design. I know that's difficult with a larger group, and that when the active group of developers in OFBiz was smaller we were _constantly_ discussing new feature ideas and making dramatic changes to initial ideas through those discussions. That started with the early days when Andrew and I spent hours on the phone discussing things, so much so that we changed cell phone carriers so we could use the unlimited mobile to mobile minutes on the same carrier. That continued with the various people who got involved early on too, sometimes with phone calls and often with long discussions on the mailing lists. It's definitely the case that not every little thing was discussed, and many things were discussed after a commit (which was often used to facilitate communication and solicit feedback since the contributor and user communities were both much smaller). These days there seems to be almost no discussion, and even very few requests for feedback... and understandably so as many of the requests for feedback result in very non-productive mudslinging. And yes, not every idea is a good one and many things really don't belong in the framework. Putting things in themes instead of the framework is a good idea for many things. And on the topic of themes, it would be nice (and reduce the incredible amount of redundancy in themes) if the themes were limited to visual artifacts such as images and style sheets, instead of also including various templates. Take these hugely redundant theme templates (especially for header) and combine that with the practice of parameterizing every little thing... and you have an error-prone tangle that makes customization difficult and discourages innovation and improvement in the project. Sorry for the rant, but this kind of thing has been going on for a long time and is another reason why I still maintain that the ONLY way OFBiz will ever have a clean framework separation, and even a clean framework, is if it is a separate project maintained by a different group of people than maintains the more business-oriented functionality of OFBiz. -David On Apr 26, 2011, at 4:37 AM, Scott Gray wrote: > I agree with Adrian, the style element alone already gives more that enough > control to theme designers. > > Every web developer has (or should have) at least a basic understanding of > css and every time we step away from such a standard (like with additional > attributes in the widgets) we make OFBiz a little harder to use and maintain, > it's plenty hard enough already. Not every idea is a good idea and not every > good idea is really needed. > > Regards > Scott > > HotWax Media > http://www.hotwaxmedia.com > > On 26/04/2011, at 8:37 AM, Adrian Crum wrote: > >> Main style sheet: >> >> .button-bar ul a.create,.button-bar a.create { >> padding:6px 10px 6px 10px; >> } >> >> Optional icons style sheet: >> >> .button-bar ul a.create,.button-bar a.create { >> background: url(../images/button_sprite.png) no-repeat 0px 0px; >> padding:6px 10px 6px 30px; >> } >> >> No changes to markup needed. It is the same thing we do to switch rendering >> from LTR to RTL. >> >> -Adrian >> >> On 4/25/2011 1:19 PM, Nicolas Malin wrote: >>> Your are against me ? My popularity increases :) >>> >>> At this time : >>> Screen definition : >>> ------------------------ >>> <link target="EditExampleLayer" ... style="buttontext create"/> >>> >>> >>> Output html render : >>> --------------------------- >>> <a class="buttontext create" id="FindExample_LF_1_link" >>> href="javascript:void(0);">Nouvel exemple</a> >>> >>> Style theme definition : >>> ------------------------------ >>> style.css : >>> .button-bar ul a.create,.button-bar a.create { >>> background: url(../images/button_sprite.png) no-repeat 0px 0px; >>> padding:6px 10px 6px 30px; >>> } >>> >>> >>> My proposition, after your first remark : >>> Screen definition : >>> ------------------------ >>> <link target="EditExampleLayer" ... style="buttontext"> >>> <icons name="add"> >>> </link> >>> >>> Or >>> <link target="EditExampleLayer" ... style="buttontext" icons="add"> >>> >>> Or >>> <link target="EditExampleLayer" ... style="buttontext" purpose="add"> >>> >>> >>> Output html render : >>> --------------------------- >>> <a class="buttontext add" ... >Nouvel exemple</a> >>> >>> Style theme definition : >>> ------------------------------ >>> icons.css : >>> .button-bar ul a.add,.button-bar a.add { >>> background: url(../images/button_sprite.png) no-repeat 0px 0px; >>> padding:6px 10px 6px 30px; >>> } >>> >>> What's changes ? What is broken? Your are against widgets controlling >>> styling but at this time all icons define by style attribute on elements to >>> be used by theme. I propose more fexibility to explain the element's >>> purpose that will be work by screen renderer and after by theme designer. >>> >>> To continue update icons improvement : >>> <set field="iconsModeViewEnumId >>> from-field="userPreferences.VT_ICONS_MODE_VIEW"/> <!--If User whant to view >>> icons--> >>> <set field="iconsStyleLocation" from-field="userPreferences.VT_ICONS_" >>> global="true"/><!--If User have preference on icons to use--> >>> <service service-name="getIconsVisualThemeResources"><!--return the css >>> file to use that contains icons definition--> >>> <field-map field-name="visualThemeId"/> >>> <field-map field-name="iconsModeViewEnumId"/> >>> </service> >>> >>> Nicolas >>> >>> Le 25/04/2011 14:25, Adrian Crum a écrit : >>>> I'm against the idea of widgets controlling styling. Period. I am against >>>> Nicolas or any other developer deciding which icons get used and where - >>>> that is a decision that should be reserved for theme designers. >>>> >>>> To summarize my view: >>>> >>>> 1. Icon display and the choice of icons should be left to the theme >>>> designer. Therefore, icon references should be kept in stylesheets. >>>> 2. If a theme designer wants to give the user an option to use icons or >>>> not, then the theme's templates can conditionally load a cascading >>>> stylesheet that includes icons. >>>> >>>> -Adrian >>>> >>>> On 4/25/2011 5:14 AM, Jacques Le Roux wrote: >>>>> On a second thought, we may use another technology than CSS and still >>>>> have styles, see for instance in POS: posstyles.xml. So yes, >>>>> styles add flexibility and independence. >>>>> >>>>> At 1st glance, Adrian's proposition sounds better from flexibility POV. >>>>> But, if I have well understood, is still limited to icons or >>>>> not in the whole OFBiz (like Google bar) when Nicolas's allows to set it >>>>> by screens (why not even by form fields or menu entries?) >>>>> >>>>> I think this is really an important point in UI and should be discussed >>>>> by the whole developers community, any other opinions, >>>>> suggestions? >>>>> >>>>> Thanks >>>>> >>>>> Jacques >>>>> >>>>> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>>>>> You can control icon display through user preferences without embedding >>>>>> the icons in markup. A user setting can conditionally load >>>>>> a stylesheet that references the icons. >>>>>> >>>>>> I'm not against having new icons in the project. An expanded selection >>>>>> of icons is a great tool for theme designers to use. But >>>>>> their use should be determined by the theme designers - not by screen >>>>>> widgets. The OFBiz community has worked hard over the past 4 >>>>>> years trying to get styling out of markup and into stylesheets. I will >>>>>> push hard against any effort to reverse that. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> On 4/25/2011 1:32 AM, Nicolas Malin wrote: >>>>>>> Adrian I understand your remark but I'm not completely in agreement >>>>>>> with that. >>>>>>> >>>>>>> Icons is at once of the most visual but also a help user. We could >>>>>>> associated directly to a themes but the reality is more >>>>>>> complex. If I take the GTK project, every user can define if he wants >>>>>>> icons, icons and text or only text independently of the >>>>>>> themes. >>>>>>> >>>>>>> On issue OFBIZ-4259 I do an error to use icons through img because >>>>>>> although they are images, they are a more complex management. >>>>>>> >>>>>>> I'm not for their exploitation only through css or style because >>>>>>> although they results from it. We limit their display rendering >>>>>>> on one technology et style don't allow user preference managment. >>>>>>> >>>>>>> I propose to continue icons integration, add a new element in screen >>>>>>> renderer that indicates what icons use on menu and form >>>>>>> field. Thence following the user preference and then the themes we >>>>>>> display icons or not. Whether rendering css by then or >>>>>>> treatment with an image, it will be template renderer are made their >>>>>>> work. >>>>>>> >>>>>>> Nicolas >>>>>>> >>>>>>> >>>>>>> Le 25/04/2011 05:21, Ryan Foster a écrit : >>>>>>>> I thought the original idea that Nicolas proposed, was for this to be >>>>>>>> configurable by theme (adding a >>>>>>>> layoutSettings.VT_ICONS_LOC to data config). I think that you should >>>>>>>> be able to turn icons on and off as well as change the >>>>>>>> icon library location. >>>>>>>> >>>>>>>> Ryan L. Foster >>>>>>>> 801.671.0769 >>>>>>>> cont...@ryanlfoster.com >>>>>>>> ryanlfoster.com >>>>>>>> >>>>>>>> On Apr 24, 2011, at 6:29 AM, Adrian Crum wrote: >>>>>>>> >>>>>>>>> The main problem I have with this is the idea that theme design has >>>>>>>>> been taken away from the theme designer. In other words, >>>>>>>>> icons should be added by the theme designer - they should not appear >>>>>>>>> in all themes by default. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> On 4/24/2011 5:26 AM, Jacques Le Roux wrote: >>>>>>>>>> It's actually related to >>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-4259 and r1095984 >>>>>>>>>> >>>>>>>>>> I did not see any issues in Flat Grey, could you post a screenshot? >>>>>>>>>> >>>>>>>>>> If it's really blocking (I doubt we can't fix any related issues), >>>>>>>>>> it should be easy to configure with a property in >>>>>>>>>> widget.properties to bypass image rendering in menus >>>>>>>>>> (HtmlMenuRenderer.java around line 500) and buttons >>>>>>>>>> (MacroFormRenderer.java look for >>>>>>>>>> submitField.getImageLocation(context) or maybe rather >>>>>>>>>> ModelFormField.java but this one >>>>>>>>>> existed before, see >>>>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=1095984 for >>>>>>>>>> files changed) >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>> From: "Adrian Crum"<adrian.c...@sandglass-software.com> >>>>>>>>>>> I see that icons were added to menu items - maybe in rev 1088549. >>>>>>>>>>> Is there a chance we can revert that? Or at least make it >>>>>>>>>>> configurable on a per-theme basis? The new icons break the layout >>>>>>>>>>> in the Flat Gray theme. It would be helpful if a theme can >>>>>>>>>>> choose to use the icons or not use them. >>>>>>>>>>> >>>>>>>>>>> -Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >
