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

[REBOL] Re: Looking For Help

From: petr:krenzelok:trz:cz at: 29-Jan-2003 12:30

Hi, 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: http://www.reboltech.com/downloads/changes.html - 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 <!--[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 knows :-) Cheers -pekr- Jim Richards wrote: