[REBOL] Re: Looking For Help
From: petr:krenzelok:trz:cz at: 29-Jan-2003 12:30
although I don't know any details about how you use templates etc., I
will elaborate a bit.
Rebol does know how to deal with scripts embedded into websites. You can
find some info upon latest releases here:
- look for build-tag and build-markup functions and code examples ...
However - that is not sufficient model for me. I strictly require
division between database information maintainer, web designer and web
programmer. That is not currently easily possible, unless programmer
sends each time his work to web designer. Current aproach also limits
webdesigner into how he/she designs webpage. He/she can't see the
design, if e.g. you are required to build-table by script. Then your
code has to carry also design information ...
Build-markup is nearly there, but not exactly there :-) Simply
everything in between:
*<% email %>
is being evaluated ...
But whole your .html file is treatened as one context. What happens if
you have several tables in one html file, and need two 'email words? I
don't want to use e.g. <%user/email%> and <%company/email%>.
I will soon try to design following aproach - encapsulated modules,
which know how to behave. So - website designer marks start and end of
<!--[module: "abc" version: 1.0.2 config: [dialect here]]-->
I am not sure it will look exactly that way, but it will be something
like that. I can even go for component/modules architecture (plug-ins).
My first example will be - tables. I want to give designer a freedom, so
he/she can e.g. design whole table design, and mark certain sections for
me. Or he can just desing one row of table, and instruct me to repeat
the rows and take amount of rows from cgi variable or directly from dialect.
Does your designer want to go for two tables design, change color,
style, etc.? Who cares? Let him do so, my module should know how to
parse his/her requirements ...
Later on, for some environments, some plug-ins could be created to allow
configuration of module ....
So, that is how I am thinking about the problem. I yet have to implement
it. Our first kiosk system is running, and now is time for a little
abstraction. I will try to implement what I described, but maybe I will
fail, as there seem to be noone else here thinking in the same way and
maybe the code will be too have and complex, difficult to use - who
Jim Richards wrote: