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

[REBOL] Re: template driven development? Re: Rebol Server Pages

From: brett:codeconscious at: 11-Oct-2002 1:09

Hi Petr,
> >I'd like a nice REBOL specific solution to this issue as well (I want to > >rebuild in a more context aware way than the string > >approach I'm using now). I envisage that I'll use XML (XHTML +
> >as a editing space for my page design. The page design will be sucked up
> >transformed to some sort of REBOL model or dialect. > > > I don't want to invent yet-another-aproach-to-build-websites. I want let > designer his/her freedome to use tools which exist - FrontPage, > DreamWeaver, etc. So the only suitable path for me is - custom tags, > specific API (e.g. dialect), which will be handled on server ...
Yes were are talking about the exact same goals, although I am interested in various ways to build websites. I think integrating with a designer tool is important. I like the idea of the dialect/api/modules. Look for opportunities that the tools offer. For example, I know that Dreamweaver has a couple of reuse mechanisms built in (eg. library). Frontpage probably would too. Such library entries could possibly be more comfortable for your designer to use than manually entering special embedded codes. I can't remember now, but the library entries may also provide a sort of example view. Don't forget SSI (server side includes) in you considerations.
> > I'll then need a > >processing model (hopefully the same dialect) that can bind my content to > >these page designs and finally something to emit the markup. > > > I don't want to bother with emiting markup at all if possible ...
Hmm, on the other hand maybe we are not talking about the same goals :^) I guess a question you need to ask yourself is this - is your API/dialect going to "understand" the markup that the designer has created around it so that relates to specific tags as parent or child etc (some sort of document model) or is it going to simply treat the markup the designer creates as simply as a string like the new build-markup function or RSP does? I don't know if there are other possibilities. I doubt there's a magic solution - more likely a continum of sophistication vs a set of requirements :^) Regards, Brett.