Skip to Content

Changes for page WO Builder Ideas

Last modified by Marc Oesch on 2006/10/25 12:13
From version 43.3
edited by Marc Oesch
on 2023/11/13 11:55
Change comment: Update document after refactoring.
To version 43.1
edited by Marc Oesch
on 2006/10/25 12:13
Change comment: Migrated to Confluence 4.0

Summary

Details

Page properties
Parent
... ... @@ -1,1 +1,1 @@
1 -WOL.Home.Deprecated info.WebHome
1 +Deprecated info
Content
... ... @@ -1,6 +1,6 @@
1 1  This page discusses ideas for a WOBuilder replacement / successor / clone and ideas how to achieve it. Below are excerpts pasted from various ideas from the WO mailing lists. Please add and update your ideas here to keep the page up to date.
2 2  
3 -A separate page for active projects is available here [[doc:WOL.WO Builder Tasks]] .
3 +A separate page for active projects is available here [[doc:WO Builder Tasks]] .
4 4  
5 5  == General Idea for additional tool: Split WYSIWYG/web designer and developer needs ==
6 6  
... ... @@ -35,10 +35,10 @@
35 35  For the BVM - that's the Baby's View Modeler that would substitute WOBuilder - I'd like I could start working from a high resolution graphic or SVG design made by a professional designer.
36 36   I would then go along marking areas on the picture and saying 'this is going to be a WOForm; these, WOButtons', so that the corresponding web server resources would be automatically created (and properly linked) at different resolutions for different CSS "media" tags, browsing device capabilities, user preferences, etc.
37 37  
38 -In the BVM too I'd like to be able to select a flow, or more than one, of page portions[[doc:WOL.1]] that would be presented in some meaningful sequence to the client browser[[doc:WOL.2]].
38 +In the BVM too I'd like to be able to select a flow, or more than one, of page portions[[doc:1]] that would be presented in some meaningful sequence to the client browser[[doc:2]].
39 39  
40 -[[doc:WOL.1]] something like the flowing you can do in Acrobat,
41 - [[doc:WOL.2]] something like a wap stack.
40 +[[doc:1]] something like the flowing you can do in Acrobat,
41 + [[doc:2]] something like a wap stack.
42 42  
43 43  I know I'm showing my bias thinking again on small real state devices, but if it is awkward to develop for three different desktop browsers, developing for a myriad of small devices is plain crazy. All this should be automated from the beginning to the extreme... and the extreme could be some clever D2W presentational rules that would even take into account if the presentation flow is going to be managed from the server or from the client (some small devices are really stupid). On second thought, something similar could prove useful too for designing whatever substitutes ajax in the future
44 44