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