Hello Erich, list. sorry for the late reaction ( I did have to work yesterday.) > Hi everyone > > I like Eric's 2nd drawing and the model it presents. I am XML illiterate > and therefore can not judge how complex a translator for the actual > templates to be deployed might be. This translator is everywhere available. With the xml you can use an "transform Stylesheet". ( it is something like CSS if you are more familiar with that. for each item you can define what the interpretator has to do with the xml script as an example (attention this is pseudocode and doesn't work, It is only to express my idea) if in a configration file there is an optional option "us" "ch" "nl" that determines the nationality this would look something like : <item type="optional" required="not" multichoice="yes" name="nationality"> <option>us</option> <option>ch</option> <option>nl</option> <help>select your nationality</help> <doc>this option can be used ..............dsdfsffsdfdfff< /doc> </item>
You could have a stylescript "webpage.xsl" that would do ; for each item if it is an option then write in the html file <tr> <td><select> the content of the attribute name for each option write <option> content of option </option $option)> <select> </td> </tr> ( I know this is only pseudocode) Another stylesheet "documentation" for each item write name and content of doc file. Another stylesheet "simple setup" for each item with attribute basic write the option otherwise select the options that is indicated. The stylesheet parsing rules option="" [ `grep ^option ` ] && option=checked etc. So you use the xml file as database and extract from it just what you need. The stylesheets are not only useable for ppp.lrp but also for isdn, shorewall or whatever you want. Advantage from xml over a database is that it is operatingsystem independent. It can be created with an editor, everybody that want another display can adapt a stylesheet, even without nowing something about the module at all. The "intelligence" is in the database (xml ) Eric's model has the potential to not > only be applied to a configuration UI but actually to the build of a > custom distribution, but this strays off the topic I am afraid. > > Charles pointed us at Forth, which sounds like an engineers choice. It > might be a good choice but I believe the strength of the LEAF project (and > many other OSS projects) lies in its quality and adaptability by a > prospective user. I believe in this aspect Forth will not qualify. I can see the use of Forth for certain aspects of the distro. ( how often does the user look at the /linuxrc script. What would it matter, if the whole start-up would be done in forth and not by shell scripting. Even the parsing-rule script I wrote about before could be possible automatically generated in Forth ( as far as I remember is this a stack orientated language.) And this would run a lot faster. As a user and even as a developer of the configuration, I wouldn't mind being Forth "intermediate" between the part I read and can edit " xml script" and the part that gives me my variables. ;) > Using simple HTML templates with placeholders for the actual values to be > drawn and standardising such templates would allow anyone to contribute > easilyy. Tools for this simple model are easy and abundant. Agreed see above. > Nathan wanted embedded inline scripting in the HTML and a few other goodies > on the server. I have a very reserved opinion about scripting in HTML, in > my opinion it clutters data with presentation even worse than normal HTML. > On top of that it requires an interpreter on the server and I believe we > should stay tiny here. But that of course is just an opinion ;-) We still need a kind of an interpreter on the server, as long as we don't want to be dependent of the browser. Somebody has to do the calculation, and the only side I can control ( as a developer) is the server side. ( for example I don't like to have to use javascript ). > Eric, where do you see the benefit of generating the parsing rules from > XML, would it not rather add another level of complexity? I hope I explained why . I think it would simplify the development for the second and third packages :) > > > I think I prefer the first option (xml). > > > > > > I would prefer this method as well. I have only one question, > > > will the XML need an interpreter on the www-server? > >No it is not even available on the router as the xml files are only used > >to generate the > >"parsing rules", "html template" and "config template". > >I just have to be more precise with describeing ; ) > > cheers > > Erich Cheers Eric ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
