Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

RFC: Forms generator / RAD dialect

 [1/12] from: robert:muench:robertmuench at: 20-Aug-2002 19:16


Hi, most applications share a few very basic concepts: - You have a set of business objects - You want to edit business objects - You want to store / load business objects - You want to reference business objects from other business objects IMO this functionality is needed in 90% of all applications. At least for thos applications handling some data stuff and that normal people would implement using a RDBMS. Well, I don't want to use a RDBMS I want to use Rebol. But I hate repetitive tasks, especially creating very basic GUI forms. So why not use Rebol for this? Thing like this shouldn't be written by hand: lab "Company" company: fld return lab "Contact" contact: fld return lab "Title" titl: fld return lab "Phone" dial work: fld return lab "Email" [mailto email/text] email: fld return lab "Web" [brws web/text] web: fld return lab "Address" smail: ari 200x40 return lab "Alt Phone" dial cphone: fld return lab "Info" info: ari 200x72 return lab "Notes" view-notes notes: ari 200x72 return lab "URL 1" [brws url1/text] url1: fld return lab "URL 2" [brws url2/text] url2: fld return lab "Updated" updat: inf 200x20 return Instead I'm thinking about a dialect to specify such a section. And one nice side effect would be that the dialect can be written by users not familiar with Rebol. How about this? address!: [ ; Name Text Type Action company "" field streams "" field [unfocus update-list focus read-list] description "" field cln-id "Customer" field [read-only] ... ] Now we need a GUI form generator that gets such an input block and creates a layout block for us. The result should be something like this: lab "Company" company: fld return lab "Streams" streams: fld [update-list] return lab "Description" description: fld return lab "Customer" cln-id: info return Did anybody started something like this already? What do you think? Anyone interested in working on such a thing? IMO it would help us a lot to have such a RAD dialect for classical database applications. Here is a very basic prototype of the idea: rad-styles: stylize [ lab: text 90x20 right bold middle font-size 11 btn: btn 64 tgl: btn 64 fld: field 200x20 font-size 11 middle edge [size: 1x1] inf: info font-size 11 middle edge [size: 1x1] ari: field wrap font-size 11 edge [size: 1x1] with [flags: [field tabbed]] ] project!: [ ; Name Text Type Action id streams description cln-id cln-prj-id date-start date-end ] output: [ styles rad-styles across ] generator: [ some [ set field word! ( repend output ['lab to-string field to-set-word field 'fld 'return] ) ] ] parse project! generator ?? output view layout output Robert

 [2/12] from: greggirwin::mindspring::com at: 20-Aug-2002 17:37


Hi Robert, I've thought about things like that, but haven't pursued them at any length. I always seem to come up with more features it should support and putting it off as it grows. Given an object itself, you should be able to create a basic edit screen dynamically for it, though it would be fairly limited. The next step, for me, was to create an object/constraint definition that includes information like whether an item is from a list of choices, what value range is valid, display vs. stored values, contextual relations with other fields, etc. From there, you could have a generator run through some permutations (e.g. choice vs option vs list) and generate layouts dynamically for you to choose from, perhaps given size constraints. See what I mean about creeping-featuritis? :) I think a dialect is definitely the way to go. Kind of busy at the moment, but keep me posted about what you get going. --Gregg

 [3/12] from: atruter:hih:au at: 21-Aug-2002 10:08


<SNIP>
But I hate repetitive tasks, especially creating very basic GUI forms. So why not use Rebol for this? Thing like this shouldn't be written by hand: lab "Company" company: fld return </SNIP> I agree, but isn't the answer just to make better use of styles. eg. <CODE> to-width: func [x] [ 75 + 8 * x - 8 ] stylize/master [ ; VID types lbl: lbl blue to-width 1 field: field to-width 1 date-field: field [ if not empty? face/text [ either none? attempt [to-date face/text] [ clear face/text ][ face/text: form to-date face/text show face ] ] ] ; Derived types lab-address: lbl "Address:" fld-address: field to-width 3 lab-date: lbl "Date:" fld-date: date-field lab-code: lbl "Code:" fld-code: field ] view layout [ across lab-address fld-address return lab-date fld-date lab-code fld-code ] </CODE> Defining things in this manner means we can easily make global changes to both VID types and our derived types. I believe this approach is more efficient than trying to create a dialect that is used to essentially achieve the same result, but feel free to point out the flaws in my logic / approach. ;) Regards, Ashley

 [4/12] from: g:santilli:tiscalinet:it at: 21-Aug-2002 3:13


Hi Robert, On Tuesday, August 20, 2002, 7:16:53 PM, you wrote: RMM> Thing like this shouldn't be written by hand: Indeed, they don't. :-) RMM> address!: [ RMM> ; Name Text Type Action RMM> company "" field RMM> streams "" field [unfocus RMM> update-list focus read-list] RMM> description "" field RMM> cln-id "Customer" field [read-only] RMM> ... RMM> ] Mmm, looks like dbgui-wizard.r. :-) RMM> Now we need a GUI form generator that gets such an input block and RMM> creates a layout block for us. The result should be something like this: It actually does better, by handling object-to-gui and gui-to-object translation, and a few other things. (When you insert a record in the db, any browser that shows that table etc is refreshed to chow the new record, and so on.) RMM> Did anybody started something like this already? What do you think? It's here and working. But I'm going further; there's some chance I'll release, by the end of this week, a very preliminary version of Road (Rapid data Oriented Application Development), an IDE designed to automatically create RDBMS-based applications. I warn you that this preliminary version is not that great, and is not much automatic, but it is a start. I'm not sure if it will be useful to release it publicly, or wait for something more usable first. (The final goal is to write a piece of software that, given relational schema and some additional information --- such as help text for the user, and so on --- will create a REBOL or PHP application to browse-insert-modify the data in that DB. I'm doing this for my degree too.) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [5/12] from: chris:langreiter at: 21-Aug-2002 20:09


RMM>> Thing like this shouldn't be written by hand:
> Indeed, they don't. :-)
Does anyone of you know Naked Objects? http://www.nakedobjects.org/ It largely deals with the same issues (specifying a "model" and having an application built more or less automatically). Interestingly, Microsoft once did (or tried) something similar as well in their (now-disbanded) Second Foundation group: http://ofb.net/~egnor/resume/notes.html#semplat (UI drivers) I've wanted to build something like this in REBOL for quite some time now ... and I'm not the only one (or so it seems) ;-) After all, REBOL is the perfect language for the declarative side of life ... -- Chris

 [6/12] from: robert:muench:robertmuench at: 22-Aug-2002 9:40


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 5>>
> at any length. I always seem to come up with more features it > should support and putting it off as it grows.
Hi, I know this problem but I can control myself quite OK to keep realistic in the first try and evolve the stuff over time. Further I try to find someone to use the stuff I do for getting real-life feedback. I'm not a friend of the concept: Hey, I have a solution does anybody has the problem it solves?
> Given an > object itself, you should be able to create a basic edit > screen dynamically for it, though it would be fairly limited.
IMO it depends on. My idea is to use templates of forms that support different edit concepts. Than you just specify: edit-concept form, list, tree etc. These templates can be quite complex and the templates just containd an area where the dynamically created fields etc. will be placed. Just a rough idea yet.
> From there, you could have a generator run through some > permutations (e.g. choice vs option vs list) and generate > layouts dynamically for you to choose from, perhaps given > size constraints. See what I mean about creeping-featuritis? :)
;-)) How about adding a useability simulation model and have the generator select the best layout itself ;-)) We talke in a couple of years about such a feature... Robert

 [7/12] from: robert:muench:robertmuench at: 22-Aug-2002 9:40


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 3>>
> Subject: [REBOL] Re: RFC: Forms generator / RAD dialect > Mmm, looks like dbgui-wizard.r. :-)
Hi, never looked at it yet. I'll have to check out. Where can I find this script?
> It actually does better, by handling object-to-gui and > gui-to-object translation, and a few other things. > (When you insert a record in the db, any browser that shows > that table etc is refreshed to chow the new record, and so on.)
Ok, I see. This implies that you use a database in the background. I have thought about a concept to describe a data model that fits smoothly into such a dialect. Further the representation model of the data and the storage used should be customizable. I have come up with a very generic concept how to handle this. But it's not perfect yet, I still need some time and first have to test some prototypes.
> But I'm going further; there's some > chance I'll release, by the end of this week, a very > preliminary version of Road (Rapid data Oriented > Application Development), an IDE designed to automatically > create RDBMS-based applications.
This sounds interesting. Especially I will focus on the dialect and the concepts first and (maybe) later think about a GUI editor for this. I hope other will take the plunge and do it ;-))
> I warn you that this > preliminary version is not that great, and is not much > automatic, but it is a start. I'm not sure if it will be > useful to release it publicly, or wait for something more > usable first.
Golden rule of open-source software: Release early, release often ;-))
> (The final goal is to write a piece of software that, > given relational schema and some additional information --- > such as help text for the user, and so on --- will > create a REBOL or PHP application to browse-insert-modify the > data in that DB. I'm doing this for my degree too.)
Ok, I have done such a thing with JavaScript and PHP. We have made a complete framework. We even had some basic concepts from IOS, server callable functions etc. There was a framework debugger running on the client, that was implemented in JavaScript. Very cool! But my friend and I recognized that we reached the limit of what can be done with such a concept and the available web technology. That's why he had a deeper look into Curl and I into Rebol ;-)). And we now just start to think about a new version but this time with the better technology base. Robert

 [8/12] from: robert:muench:robertmuench at: 22-Aug-2002 9:40


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 3>>
> Subject: [REBOL] Re: RFC: Forms generator / RAD dialect > I agree, but isn't the answer just to make better use of styles. eg.
Hi, I don't know. I won't call me a VID expert at the moment. My goal is to let people that don't know how to program, that don't know about Rebol write down a specification of there needs and have a generator do the rest. These kind of people understand the concept of a button and an associated action that's it.
> <CODE> > ; Derived types > lab-address: lbl "Address:" > fld-address: field to-width 3
Hm... This is very domain specific. It should be more general.
> lab-date: lbl "Date:" > fld-date: date-field
A Date field with calendar selector etc. is OK. This is just a heavy weight widget that can be used. I see these things positioned into a widget-library or functions that assemble lower-level into higher-level widgets.
> Defining things in this manner means we can easily make > global changes to both VID types and our derived types.
For the developer of the framework I agree. The user of the dialect doesn't care about it.
> I believe this approach is more efficient than trying to create > a dialect that is used to essentially achieve the same > result, but feel free to point out the flaws in my logic / > approach. ;)
As said, IMO it's a question about what kind of target users you see. I see my friends not able to program and begging me for this and that app. If I can concentrate on the framework let them do there little reblets themself. Robert

 [9/12] from: al:bri:xtra at: 22-Aug-2002 21:06


Chris wrote:
> Does anyone of you know Naked Objects? > > http://www.nakedobjects.org/ > > It largely deals with the same issues (specifying a "model" and having an
application built more or less automatically). Looks very nice! I must write it in Rebol! Andrew Martin Rapidly removing clothes... ICQ: 26227169 http://valley.150m.com/

 [10/12] from: g:santilli:tiscalinet:it at: 22-Aug-2002 12:38


Hi Robert, On Thursday, August 22, 2002, 9:40:35 AM, you wrote: RMM> Hi, never looked at it yet. I'll have to check out. Where can I find RMM> this script? Never released publicly, because it's not really finished. If you are really interested, I can send it to you so you can have a look. RMM> This implies that you use a database in the background. Not necessarily. What you really do with the data is up to you. I currently have functions that allow to set up event chains; you are then able to fire up events in your code (e.g. New-client-object-to-insert etc.) and then listen to that kind of event in other parts of your code (i.e. the DB abstraction layer that takes care of actually insert the data in a DB, or a browser for client objects that should update its display, or a selection list in some form that should add the new object to the list, and so on). RMM> generic concept how to handle this. But it's not perfect yet, I still RMM> need some time and first have to test some prototypes. As I said, it was written only to fit my needs thus not publicly released; however, as times goes on, I'm going to try to make it more generic; so, even if my code will not be useful to your project, maybe I can contribute some thoughts. :-) RMM> Golden rule of open-source software: Release early, release often ;-)) You're right, but that might then set compatibility requirements with badly designed early code... ;-) RMM> I recognized that we reached the limit of what can be done with such a RMM> concept and the available web technology. I will probably be asking questions in the future then, since discovering the limits of such an approach is what my teacher is interested in. :-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [11/12] from: greggirwin:mindspring at: 22-Aug-2002 10:34


Hi Robert, << How about adding a useability simulation model and have the generator select the best layout itself ;-)) >> Actually, if you don't care what the user sees, let them pick which one *they* like. Just keep track of which screen it is, or what heuristics were used to generate it so you can duplicate their layout on your system if necessary. Kind of the way some card or puzzle games let you select a game number. This is kind of what Volker did for the slashdot viewer project. Not exactly the same because each one is truly a separate app, but the users gets to pick which one they like. --Gregg

 [12/12] from: robert:muench:robertmuench at: 25-Aug-2002 12:02


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 5>>
> If you are really interested, I can send it to you so > you can have a look.
Hi, yes please. It's always good to see different implementations.
> As I said, it was written only to fit my needs thus not > publicly released; however, as times goes on, I'm going to > try to make it more generic; so, even if my code will > not be useful to your project, maybe I can contribute some > thoughts. :-)
I hope so. There was a discussion some time ago about the "associative data model". IMO that's the killer way to go for IOS! And that's what I now going to implement. I use the "associative data model", business objects, relations etc. and want to build a generic application to handle all kind of business requirements. I don't see why we need specialized applications? The next thing will be to generate the appropriate GUI on the fly. IMO we need specialized GUI's depending on what you want to see, do etc. But the data model should be completely decoupled.
> You're right, but that might then set compatibility > requirements with badly designed early code... ;-)
No, no. Compatibility is way to much overestimated. Just provide some migration tools ;-))
> I will probably be asking questions in the future then, > since discovering the limits of such an approach is what my > teacher is interested in. :-)
No problem. Just let me know. Robert

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted