Hello Ean, That was a great metaphor that you used. In fact, my inspiration to continue battling seemingly impossible tasks has been a car design & execution effort - Tata Nano - world's cheapest(!) car - http://www.counterjumper.com/2008/01/11/tata-nano-making-the-impossible-possible/.
Ean Schuessler wrote: > > David E Jones wrote: >> The general idea is an interesting one, ie of really separating things by >> role and eliminating dependencies. >> >> I like the stuff you guys at Brainfood have done with WebSlinger, and it >> certainly makes things easier for people in certain roles. >> > Webslinger definitely makes certain things easier but it also destroys > the portability proposition of the widget system. We are currently > looking at supporting form widgets as a native document type in > webslinger, which may restore some of that portability. > > One thing I have been curious about is building a XUL renderer, which > should be pretty thin. >> In a way I wonder if points #1 and #2 that I listed above are actually >> possible. My theory over the years is that they are simply not possible, >> and all attempts are guaranteed to fall short because those requirements >> are not "internally consistent". It would be interesting to have a >> well-funded R&D project to get feedback from a bunch of people, assemble >> a number of possible designs, then implement and test those designs in >> various organizations. I'm not sure if that will ever happen, and I >> suppose even if it did the winning design would probably be so biased by >> politicking that the stated result might not be accurate. >> > Actually I think this is essentially going on and has for some time. I > think the difficulty of the problem is why there are so many "web > frameworks". There is no clear solution so people keep throwing things > up to see if they will stick. > > I think the fundamental disconnect is analogous to automobile body > design -vs- powertrain design. On the one hand, you have people that > want to draw pictures of awesome looking cars and on the other hand you > have people who want to tackle physics problems to deliver power in a > system. Making those things blend together seamlessly, as you indicated, > requires an understanding of all the principals involved. Great > industrial design combines the intuition of art with the rigid demands > of engineering and you can't really get one or the other for free. >> Anyway, it's a tough problem. The main issues I see are kind of like what >> you listed Ean, namely: >> >> 1. different organizations have different roles and different skills >> sets, so to be effective you'd really need to document a variety of >> organizations and combinations of skill sets and be flexible enough to >> address at least a few of the most common ones, or the ones that should >> be most easy for an organization to assemble >> >> 2. it's not possible to completely eliminate dependencies between what >> different people in different roles are doing; there might be some things >> you could do to either mitigate (handle automatically or >> transparently/implicitly) or obviate (fail fast/early) the problems, but >> these dependencies are an inherent part of what is being built and IMO >> they simply cannot be totally eliminated, especially if you want reusable >> parts of the screens, etc >> >> My favorite approach so far to getting people to handle this well is to >> divide front-end developers into those who are mostly visually talented, >> and those who have gotten into scripting and such too. These people will >> have to get used to working together in order to get things done, IMO. >> From time to time you'll run into a person that is great at both, but not >> usually. Those who are into scripting and working with straight HTML can >> usually get into using the OFBiz widgets and FTL templates and do quite >> well with them (and without very much training too). But that isn't >> everyone, and you certainly need someone who can break things down and >> implement the technical things to drive them. >> >> Some tools make this easier, and therefore require less technical >> knowledge, but those tools typically also restrict what you can do. If >> you want to keep it cheap and simple then that's great, just do what the >> tool makes easy. If you really want to be able to design and build >> anything that is "internally consistent" then you're going to need more >> flexible tools and more knowledgeable people. >> >> Or am I wrong and the silver bullet solution does exist and I just >> haven't yet had the pleasure of experiencing it? >> > Even HTML is almost still too far into the engineering realm. The truly > beautiful tool is Photoshop, which makes the process of image creation > almost totally artistic and lets you forget that you are manipulating > data structures. In the free software world, Inkscape is actually quite > impressive in this way. You can totally forget that you are manipulating > SVG and simply draw. There is really no analog for this in the HTML > world, especially because of CSS. > > In some ways, SquareSpace.com's online web design tool approaches what > I'd like to see a tool do, though it introduces many limitations. I'd > encourage everyone to look at its demo video. If we could provide a CMS > tool that acts like that and expose the power of the OFBiz business > logic into it, the world would be ours. >> Hopefully this time I'm less snarky, without being too depressing... :) >> > A tough problem can be fun. > > -- View this message in context: http://n4.nabble.com/Using-Apache-Wicket-in-Ofbiz-presentation-layer-tp975468p977539.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
