You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
(57) |
May
(287) |
Jun
(166) |
Jul
(286) |
Aug
(273) |
Sep
(254) |
Oct
(144) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alex B. <en...@tu...> - 2001-05-18 19:34:18
|
> Finally hacked a working version, after adding better error handling to > Alex's script :-) heh, post it! the errors I get from sablot are usually pretty useless. the errors I get from sabcmd on the command line a _great_! use that, if you're having problems. but you can't on windows :( > One of the problems was the encoding declaration - I used > encoding="utf-8". I also removed the > xmlns:fo="http://www.w3.org/1999/XSL/Format" reference and it seemed to > work fine. The fo: is there for different reasons, and you're right, it won't effect the current xsl. UTF, though I'm surprised by. > The main problem was that sablotron was looking in C:\apache for the xml nd > xsl files, when they were installed in > C:\apache\htdocs\xslt_example Anyone have an idea why this was??? I'm willing to chock that up to a funky win php install. I haven't found any installable version of php for win that didn't require a good deal of hand tweaking and head scratching to get working. check out the "complex" example I posted earlier, as it appears to be (gasp!) actually useful! the final xml output from the builder classes will be somewhat different than that little hacked format (or at least at first) but I'm seriously loving xslt. I fixed a little rule in there this morning that (for a select) checks to see if the next element is a select, and if so, prints a space - or if the next element is something else, prints a br, or if nothing, ptints nothing. it's extremely groovy, and efficient. _alex > Peter. > > > --oOo-- > Narrow Gauge on the web - photos, directory and forums! > http://www.narrow-gauge.co.uk > --oOo-- > Peter's web page - Scottish narrow gauge in 009 > http://members.aol.com/reywob/ > --oOo-- > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
From: Peter B. <re...@f2...> - 2001-05-18 19:10:36
|
At 02:36 PM 5/17/01 -0700, you wrote: > > Still won't work for me - or the new complete install. > >interesting. Finally hacked a working version, after adding better error handling to Alex's script :-) One of the problems was the encoding declaration - I used encoding="utf-8". I also removed the xmlns:fo="http://www.w3.org/1999/XSL/Format" reference and it seemed to work fine. The main problem was that sablotron was looking in C:\apache for the xml nd xsl files, when they were installed in C:\apache\htdocs\xslt_example Anyone have an idea why this was??? Peter. --oOo-- Narrow Gauge on the web - photos, directory and forums! http://www.narrow-gauge.co.uk --oOo-- Peter's web page - Scottish narrow gauge in 009 http://members.aol.com/reywob/ --oOo-- |
From: Alex B. <en...@tu...> - 2001-05-18 01:08:49
|
have a look at this, It's a complex form example. note how with xslt, there is a pretty elegant way to deal with attributes passed in by the source xml... and we can use a combination of "objects" (little sub templates for handling a specific element type in the xml), and "layouts" (larger templates which define layouts) For those of you more interested in xsl, go read this fantastic Xpath tutorial: http://www.zvon.org/xxl/XPathTutorial/General/examples.html that set of examples will get you to the point where you can write almost any kind of expression you would need. it's very well done, as is all the stuff on that site. _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
From: Alex B. <en...@tu...> - 2001-05-17 21:36:42
|
> Still won't work for me - or the new complete install. interesting. version of sablot? > Alex: are you using PHP 4.0.5? no. 404pl1, with sablot .50 _a |
From: Alex B. <en...@tu...> - 2001-05-17 21:08:43
|
> At 11:35 AM 5/17/01 -0700, you wrote: >> With good references, I was able to pick up enough to build a complex page >> in one day. it is _all_about_ the quality of your reference material, but it >> is certainly possible. > > Perhaps you could list your references? I've been learning some XSL from > the Peachpit XML book, but it was written before most of the specs were > finalised :-( > > I guess the real book to get would be the Wrox Press Professional XSLT? http://www.zvon.org/xxl/XSLTreference/Output/index.html and just googling around for examples of templates. _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
From: Alex B. <en...@tu...> - 2001-05-17 21:08:42
|
> What did you use to create the XSLT? Just a text editor, or a tool of > some sort? That is what we need, is a tool. Maybe modify Smarty to > optionally dump out XSLT instead of PHP. ;-) That last idea is freaking fantastic :) And, to answer your question, an xml-aware text editor on the mac called BBEdit, whose better I have yet to find. _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
From: Peter B. <re...@f2...> - 2001-05-17 20:57:05
|
At 11:26 AM 5/17/01 -0700, you wrote: > > Fatal error: msgtype: error in /home/mfaine/www/xslt_example/form.php on > > line 18 > >yes, this is sablot stupidness. > >anyway I attached the wrong xsl, this one fixes the problem. Still won't work for me - or the new complete install. Alex: are you using PHP 4.0.5? Peter. --oOo-- Narrow Gauge on the web - photos, directory and forums! http://www.narrow-gauge.co.uk --oOo-- Peter's web page - Scottish narrow gauge in 009 http://members.aol.com/reywob/ --oOo-- |
From: Holger B. <hb...@ya...> - 2001-05-17 20:42:17
|
>> Maybe modify Smarty to >> optionally dump out XSLT instead of PHP. ;-) Hello Monte, good idea ! Best regards, Holger |
From: Peter B. <re...@f2...> - 2001-05-17 20:31:03
|
At 11:35 AM 5/17/01 -0700, you wrote: >With good references, I was able to pick up enough to build a complex page >in one day. it is _all_about_ the quality of your reference material, but it >is certainly possible. Perhaps you could list your references? I've been learning some XSL from the Peachpit XML book, but it was written before most of the specs were finalised :-( I guess the real book to get would be the Wrox Press Professional XSLT? Cheers! Peter. -oOo- Maple Design - web design, hosting, domain names http://www.mapledesign.co.uk -oOo- |
From: Alex B. <en...@tu...> - 2001-05-17 18:38:48
|
> > I am an interface designer and I feel a little behind not knowing how to > utilize > XML and XSLT. I've dabbled with XML but never got very far with it. Does > anyone > have any basic exaples or references that utilize these presentation tools > effectively? I've attached the complete example. You need php4.0.4 w/sablot to run it. > As far as learning a new language for developing interfaces, it shouldn't be > that > bad. We've had to wrestle with everything else, and even when it takes > invisible > gifs to set the height and width of table cells and position elements, you do > it > until you find a better technique. Exactly. And for those that don't want to learn it, that's fine - they just use an extension to templatemanager that handles their template language, and go about their business. (which means that can't get pdfs automatically, etc etc etc :) _alex |
From: Alex B. <en...@tu...> - 2001-05-17 18:34:45
|
> This was "exactly" my problem, I got the hang of it at least on a > fundamental level but I could never get it to layout the page the way I > wanted, here's another question for anyone who knows? I have tons of > Javascript in some of my pages, some that sets layer text, and other bells > and whistle effects, how do you implement that in XSLT? You don't necessarily, though you can. write a template, and call it by name. It's just another normal bit of presentation. As far as XSL is concerned, the contents of < script > is just cdata. > I know you can, its just how many months am I gonna need to learn it? With good references, I was able to pick up enough to build a complex page in one day. it is _all_about_ the quality of your reference material, but it is certainly possible. as soon as you understand the aproach xslt takes, the syntax makes fairly good sense, and the processing model is logical. have a look at the (ehrm) xslt that actualy works, that I attached earlier. -alex |
From: Monte O. <mo...@is...> - 2001-05-17 18:33:18
|
What did you use to create the XSLT? Just a text editor, or a tool of some sort? That is what we need, is a tool. Maybe modify Smarty to optionally dump out XSLT instead of PHP. ;-) Alex Black wrote: > > > > I got an error on your example: > > > > Fatal error: msgtype: error in /home/mfaine/www/xslt_example/form.php on > > line 18 > > yes, this is sablot stupidness. > > anyway I attached the wrong xsl, this one fixes the problem. > > > never seen a msgtype before. > > > > -Mark > > > > -- Monte Ohrt <mo...@is...> http://www.ispi.net/ |
From: Alex B. <en...@tu...> - 2001-05-17 18:32:41
|
> This is exactly the thing I'm worried about. I don't feel that XML/XSLT > is ready for prime time use until we see GUI tools for XML/XSLT that > HTML designers can use. Maybe we can whip up something in php-gtk :-) hehe. I'm going to mention this again, in this context, because it's important: a) binarycloud will not mandate under _any_ circumstances that you use XSLT in production. b) Everything I create will use xslt. I will encourage people to build their module presentation with XSLT, through "evangelism" and by giving people help. c) with regard to gius - I think you'll see this happen very quickly, as java/jsp has support for xslt (and sun is evangelizing it) so does php, etc. _a |
From: Alex B. <en...@tu...> - 2001-05-17 18:30:48
|
> Yeah, all this stuff as been the XML hype for some time now, and as a > technology person I highly agree that XML (& XSLT) is the way to go, it > just makes sense. What my concern is how this affects the interface > designers. Right now, they know and understand HTML/CSS, and have picked > up the learning curve on how to fit it into a template language. So how > do they deal with XSLT? Learn a whole new concept/language? If they do, > how do they understand and control how XSLT outputs thier work into > HTML? They can be very picky, and may just get totally frustrated trying > to get things to look the way they want. They are already dealing with > browser bugs & inconsistancies, now they have to throw XSLT into the > mix. Speaking as a a designer (I have a strange hat on now, so I am qualified) - xslt is wonderful for all of the above. I get properly compressed output. I am forced to make clean, properly structured documents. I'm not forced, but it certainly helps to use CSS properly. etc. Yes, XSLT is a learning curve, but I don't have a problem with learning something new as long as it's better. Which is why I should re-iterate that TemplateManager can and (no doubt) will have support for all kinds of template systems, contributed by users. > Maybe I'm off base here, as I have only read about XML & XSLT and tried > rudimentary examples. I haven't tried to actually put it to use in a > production environment. But, I'm going to grab r2 and do some tests and > analysis. Well, if you grab the r2 snap I published, you don't be able to run it :) That's sort of a "directory structure" snap, it doesn't work. It will soon, though. _alex |
From: Alex B. <en...@tu...> - 2001-05-17 18:27:07
|
> I like xslt but I do believe it seems complex and overly strict. I once > tried to do my resume as xml/xslt and gave up after pulling my hair out for > 3 days trying to get the page layout right. It wasn't that I couldn't make > it work, I just couldn't make it work like I wanted it to work. I've had very, very good experiences with it so far. Can you describe a little more about what didn't work? > I got an error on your example: > > Fatal error: msgtype: error in /home/mfaine/www/xslt_example/form.php on > line 18 yes, this is sablot stupidness. anyway I attached the wrong xsl, this one fixes the problem. > never seen a msgtype before. > > -Mark > > |
From: Alex B. <en...@tu...> - 2001-05-17 18:20:43
|
> Perhaps you could remind everyone on the binarycloud-dev list to edit down > the text of the previous email. On the xslt thread we are having emails > with a few lines of new text at the top, and then the old email just > stuffed underneath, serving no purpose apart from using bandwidth. I > thought nettiquette involved quoting only enough to allow people to see > what you were on about... hi all, this is a good point, I'm probably the one most guilty, though :) so: if you get some long email from the list and want to respond, please only include the relevant parts of the message, and not the entire thread. I'll, uh, start doing this too. _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
From: <al...@th...> - 2001-05-17 15:58:00
|
I am an interface designer and I feel a little behind not knowing how to utilize XML and XSLT. I've dabbled with XML but never got very far with it. Does anyone have any basic exaples or references that utilize these presentation tools effectively? As far as learning a new language for developing interfaces, it shouldn't be that bad. We've had to wrestle with everything else, and even when it takes invisible gifs to set the height and width of table cells and position elements, you do it until you find a better technique. Alby ---- Original Message ---- Yeah, all this stuff as been the XML hype for some time now, and as a technology person I highly agree that XML (& XSLT) is the way to go, it just makes sense. What my concern is how this affects the interface designers. Right now, they know and understand HTML/CSS, and have picked up the learning curve on how to fit it into a template language. So how do they deal with XSLT? Learn a whole new concept/language? If they do, how do they understand and control how XSLT outputs thier work into HTML? They can be very picky, and may just get totally frustrated trying to get things to look the way they want. They are already dealing with browser bugs & inconsistancies, now they have to throw XSLT into the mix. Maybe I'm off base here, as I have only read about XML & XSLT and tried rudimentary examples. I haven't tried to actually put it to use in a production environment. But, I'm going to grab r2 and do some tests and analysis. alex black wrote: > > > I'm interested in seeing some examples. How does this affect the use of > > template engines, such as Smarty? > > Let me expand on this a little, so you understand the reasons: > > First, the builder classes (yes these are mysterious and not documented, I > promise this is coming soon) will all be in the business of generating > layout _arrays_ and will not in fact use any presentation code. They will > send xml to TemplateManager, with a template location, and TemplateManager > will rip the definition (xml) into whatever-you-like (PDF, html, wml, etc) > with xslt. > > So, that means we can use intelligent builder classes to generate these > arrays (xml), which can all use the _same_ presentation code. That means you > code one form layout, and you only need to code anoher form layout if you > have a special/variant form. Everything else is handled for you, down to > form element generation. For obvious reasons this is extremely powerful. > > Now, on top of that, add the ability to output PDF from the same XML that we > output html for forms, or a list (html table, or PDF, etc). Whereas before, > generating PDFs would really be quite scary, and require lots of separate > code - now it isn't scary because of xslt:fo. > > xslt has some quirks, the syntax is fairly verbose, but my initial reaction > was wrong: it isn't so verbose as to be annoying, especially when you look > at it in the perspective of a real document, where you see a lot of html, > and a bit of xslt. > > Most of the idiosyncracy comes from the element names, and the _exteme_ > strictness of the processor - because everything you write has to be valid > xml. > > After a small period of "ick", I like that a _lot_: if you are using xslt, > you are implicitly generating xhtml, and at your option, normal html 4 from > the same file. It also means your documents are quite elegant: they are well > formed, structurally correct xml docs, and they look nice. Everything is > easy to read, because the structure is imposed. > > I'm still getting use to XPath, and I need to do some experienmentation with > xsl:import, but I'm already hooked. Also, this is already a standard, and I > think you'll see a huge amount of code generated using it. > > --- > > The other thing about XSLT is it doesn't care about the output. You can use > XSLT to generate multiple versions of a php file using an XML source, you > can use XSLT to output text, csv, you name it. Because of that, it's a > fantastic general purpose tool, which we can use for all kinds of tasks. > > Ok, so how does this relate to entities, and all that? > The idea with entities is that they are essentially xml document types: > entities are hierarchical structures with nested attributes, and entity > definitions can include other entities. Entity definitions include a ton of > meta information about each attribute: the basic datatype of the entity, > maybe a regex that should be used to validate the data, the attribute name, > label, etc. All of this knowledge about the fields in your database is in a > clear, structurally sound xml file > > That means you can reference entities with xpath-like syntax, and quickly > build layout descriptions for forms, lists, trees, calendars, etc. Your > basic layouts for forms and lists/tables can reside in 2 files. That means > you can write entity definitions, and from those you can generate: > -metabase xml schemas > -forms > -lists > -displays/layouts > > with no additional code. if you want to override the "default", then you > pass in a template file. > > I hope everyone understands that concept, and why it is so powerful. If > anyone doesn't, please speak up. > > Instead of building all this markup which is unnecessary, you invest more > time in creating entity definitions, rules which govern adding and editing > entities (complex attribute relationships), and the system will take care of > a lot of the rest of the work for you. > > All of the binarycloud r2 "data flow" goes thorugh one class > (EntityManager), and is validated by the same rules - regardless of whether > your input is from an html form, an xml-rpc package, or anywhere else. And > because we have all this knowledge about entities nested in the entity > declarations, we can make edicated guesses about how the entity attributes > should be displayed - so in many cases you can establish a default, and only > rarely will you have to build files to overrirde those defaults. > > /rant. > > _alex > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev -- Monte Ohrt <mo...@is...> http://www.ispi.net/ _______________________________________________ binarycloud-dev mailing list bin...@li... http://lists.sourceforge.net/lists/listinfo/binarycloud-dev |
From: Faine, M. <Mar...@ms...> - 2001-05-17 13:54:55
|
This was "exactly" my problem, I got the hang of it at least on a fundamental level but I could never get it to layout the page the way I wanted, here's another question for anyone who knows? I have tons of Javascript in some of my pages, some that sets layer text, and other bells and whistle effects, how do you implement that in XSLT? I know you can, its just how many months am I gonna need to learn it? -Mark -----Original Message----- From: Monte Ohrt [mailto:mo...@is...] Sent: Thursday, May 17, 2001 8:44 AM To: bin...@li... Subject: Re: [binarycloud-dev] xslt Yeah, all this stuff as been the XML hype for some time now, and as a technology person I highly agree that XML (& XSLT) is the way to go, it just makes sense. What my concern is how this affects the interface designers. Right now, they know and understand HTML/CSS, and have picked up the learning curve on how to fit it into a template language. So how do they deal with XSLT? Learn a whole new concept/language? If they do, how do they understand and control how XSLT outputs thier work into HTML? They can be very picky, and may just get totally frustrated trying to get things to look the way they want. They are already dealing with browser bugs & inconsistancies, now they have to throw XSLT into the mix. Maybe I'm off base here, as I have only read about XML & XSLT and tried rudimentary examples. I haven't tried to actually put it to use in a production environment. But, I'm going to grab r2 and do some tests and analysis. alex black wrote: > > > I'm interested in seeing some examples. How does this affect the use of > > template engines, such as Smarty? > > Let me expand on this a little, so you understand the reasons: > > First, the builder classes (yes these are mysterious and not documented, I > promise this is coming soon) will all be in the business of generating > layout _arrays_ and will not in fact use any presentation code. They will > send xml to TemplateManager, with a template location, and TemplateManager > will rip the definition (xml) into whatever-you-like (PDF, html, wml, etc) > with xslt. > > So, that means we can use intelligent builder classes to generate these > arrays (xml), which can all use the _same_ presentation code. That means you > code one form layout, and you only need to code anoher form layout if you > have a special/variant form. Everything else is handled for you, down to > form element generation. For obvious reasons this is extremely powerful. > > Now, on top of that, add the ability to output PDF from the same XML that we > output html for forms, or a list (html table, or PDF, etc). Whereas before, > generating PDFs would really be quite scary, and require lots of separate > code - now it isn't scary because of xslt:fo. > > xslt has some quirks, the syntax is fairly verbose, but my initial reaction > was wrong: it isn't so verbose as to be annoying, especially when you look > at it in the perspective of a real document, where you see a lot of html, > and a bit of xslt. > > Most of the idiosyncracy comes from the element names, and the _exteme_ > strictness of the processor - because everything you write has to be valid > xml. > > After a small period of "ick", I like that a _lot_: if you are using xslt, > you are implicitly generating xhtml, and at your option, normal html 4 from > the same file. It also means your documents are quite elegant: they are well > formed, structurally correct xml docs, and they look nice. Everything is > easy to read, because the structure is imposed. > > I'm still getting use to XPath, and I need to do some experienmentation with > xsl:import, but I'm already hooked. Also, this is already a standard, and I > think you'll see a huge amount of code generated using it. > > --- > > The other thing about XSLT is it doesn't care about the output. You can use > XSLT to generate multiple versions of a php file using an XML source, you > can use XSLT to output text, csv, you name it. Because of that, it's a > fantastic general purpose tool, which we can use for all kinds of tasks. > > Ok, so how does this relate to entities, and all that? > The idea with entities is that they are essentially xml document types: > entities are hierarchical structures with nested attributes, and entity > definitions can include other entities. Entity definitions include a ton of > meta information about each attribute: the basic datatype of the entity, > maybe a regex that should be used to validate the data, the attribute name, > label, etc. All of this knowledge about the fields in your database is in a > clear, structurally sound xml file > > That means you can reference entities with xpath-like syntax, and quickly > build layout descriptions for forms, lists, trees, calendars, etc. Your > basic layouts for forms and lists/tables can reside in 2 files. That means > you can write entity definitions, and from those you can generate: > -metabase xml schemas > -forms > -lists > -displays/layouts > > with no additional code. if you want to override the "default", then you > pass in a template file. > > I hope everyone understands that concept, and why it is so powerful. If > anyone doesn't, please speak up. > > Instead of building all this markup which is unnecessary, you invest more > time in creating entity definitions, rules which govern adding and editing > entities (complex attribute relationships), and the system will take care of > a lot of the rest of the work for you. > > All of the binarycloud r2 "data flow" goes thorugh one class > (EntityManager), and is validated by the same rules - regardless of whether > your input is from an html form, an xml-rpc package, or anywhere else. And > because we have all this knowledge about entities nested in the entity > declarations, we can make edicated guesses about how the entity attributes > should be displayed - so in many cases you can establish a default, and only > rarely will you have to build files to overrirde those defaults. > > /rant. > > _alex > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev -- Monte Ohrt <mo...@is...> http://www.ispi.net/ _______________________________________________ binarycloud-dev mailing list bin...@li... http://lists.sourceforge.net/lists/listinfo/binarycloud-dev |
From: Monte O. <mo...@is...> - 2001-05-17 13:53:08
|
This is exactly the thing I'm worried about. I don't feel that XML/XSLT is ready for prime time use until we see GUI tools for XML/XSLT that HTML designers can use. Maybe we can whip up something in php-gtk :-) "Faine, Mark" wrote: > > I like xslt but I do believe it seems complex and overly strict. I once > tried to do my resume as xml/xslt and gave up after pulling my hair out for > 3 days trying to get the page layout right. It wasn't that I couldn't make > it work, I just couldn't make it work like I wanted it to work. > > I got an error on your example: > > Fatal error: msgtype: error in /home/mfaine/www/xslt_example/form.php on > line 18 > > never seen a msgtype before. > > -Mark > > -----Original Message----- > From: alex black [mailto:en...@tu...] > Sent: Thursday, May 17, 2001 12:20 AM > To: bin...@li... > Subject: Re: [binarycloud-dev] xslt > > > I'm interested in seeing some examples. How does this affect the use of > > template engines, such as Smarty? > > Attached. > > Note that this isn't r2 stuff really, I'm putzing with some ideas. > > But assuming you have sablot compiled in to php you can run this stuff. > It's surprisingly fast. > > I got _180k_ of html out of it from a 44k xml source + 5k xslt, and that > only took 1 second. > Most normal documents take in the thounsanths of seconds. > > Sablot sort of sucks, but 4.1 will solve that. > > Re: smarty: > I'm not going to build in support for smarty, but I should explicitly > mention that you can easily build a smarty subclass for TemplateManager. > TemplateManager was specifically designed to take any template type, it's a > generalized API. > > But XSLT is so unbelieveably groovy, I'll be building all my code with it. > Once you get over some of the little idiosyncracies, you realize how > powerful xslt really is. > > So the short answer is that all release binarycloud 2 modules will use XSLT > exclusively. If someone wants to write a smarty subclass for > TemplateManager, I'm happy to include it in the release. > > _alex > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev -- Monte Ohrt <mo...@is...> http://www.ispi.net/ |
From: Monte O. <mo...@is...> - 2001-05-17 13:44:46
|
Yeah, all this stuff as been the XML hype for some time now, and as a technology person I highly agree that XML (& XSLT) is the way to go, it just makes sense. What my concern is how this affects the interface designers. Right now, they know and understand HTML/CSS, and have picked up the learning curve on how to fit it into a template language. So how do they deal with XSLT? Learn a whole new concept/language? If they do, how do they understand and control how XSLT outputs thier work into HTML? They can be very picky, and may just get totally frustrated trying to get things to look the way they want. They are already dealing with browser bugs & inconsistancies, now they have to throw XSLT into the mix. Maybe I'm off base here, as I have only read about XML & XSLT and tried rudimentary examples. I haven't tried to actually put it to use in a production environment. But, I'm going to grab r2 and do some tests and analysis. alex black wrote: > > > I'm interested in seeing some examples. How does this affect the use of > > template engines, such as Smarty? > > Let me expand on this a little, so you understand the reasons: > > First, the builder classes (yes these are mysterious and not documented, I > promise this is coming soon) will all be in the business of generating > layout _arrays_ and will not in fact use any presentation code. They will > send xml to TemplateManager, with a template location, and TemplateManager > will rip the definition (xml) into whatever-you-like (PDF, html, wml, etc) > with xslt. > > So, that means we can use intelligent builder classes to generate these > arrays (xml), which can all use the _same_ presentation code. That means you > code one form layout, and you only need to code anoher form layout if you > have a special/variant form. Everything else is handled for you, down to > form element generation. For obvious reasons this is extremely powerful. > > Now, on top of that, add the ability to output PDF from the same XML that we > output html for forms, or a list (html table, or PDF, etc). Whereas before, > generating PDFs would really be quite scary, and require lots of separate > code - now it isn't scary because of xslt:fo. > > xslt has some quirks, the syntax is fairly verbose, but my initial reaction > was wrong: it isn't so verbose as to be annoying, especially when you look > at it in the perspective of a real document, where you see a lot of html, > and a bit of xslt. > > Most of the idiosyncracy comes from the element names, and the _exteme_ > strictness of the processor - because everything you write has to be valid > xml. > > After a small period of "ick", I like that a _lot_: if you are using xslt, > you are implicitly generating xhtml, and at your option, normal html 4 from > the same file. It also means your documents are quite elegant: they are well > formed, structurally correct xml docs, and they look nice. Everything is > easy to read, because the structure is imposed. > > I'm still getting use to XPath, and I need to do some experienmentation with > xsl:import, but I'm already hooked. Also, this is already a standard, and I > think you'll see a huge amount of code generated using it. > > --- > > The other thing about XSLT is it doesn't care about the output. You can use > XSLT to generate multiple versions of a php file using an XML source, you > can use XSLT to output text, csv, you name it. Because of that, it's a > fantastic general purpose tool, which we can use for all kinds of tasks. > > Ok, so how does this relate to entities, and all that? > The idea with entities is that they are essentially xml document types: > entities are hierarchical structures with nested attributes, and entity > definitions can include other entities. Entity definitions include a ton of > meta information about each attribute: the basic datatype of the entity, > maybe a regex that should be used to validate the data, the attribute name, > label, etc. All of this knowledge about the fields in your database is in a > clear, structurally sound xml file > > That means you can reference entities with xpath-like syntax, and quickly > build layout descriptions for forms, lists, trees, calendars, etc. Your > basic layouts for forms and lists/tables can reside in 2 files. That means > you can write entity definitions, and from those you can generate: > -metabase xml schemas > -forms > -lists > -displays/layouts > > with no additional code. if you want to override the "default", then you > pass in a template file. > > I hope everyone understands that concept, and why it is so powerful. If > anyone doesn't, please speak up. > > Instead of building all this markup which is unnecessary, you invest more > time in creating entity definitions, rules which govern adding and editing > entities (complex attribute relationships), and the system will take care of > a lot of the rest of the work for you. > > All of the binarycloud r2 "data flow" goes thorugh one class > (EntityManager), and is validated by the same rules - regardless of whether > your input is from an html form, an xml-rpc package, or anywhere else. And > because we have all this knowledge about entities nested in the entity > declarations, we can make edicated guesses about how the entity attributes > should be displayed - so in many cases you can establish a default, and only > rarely will you have to build files to overrirde those defaults. > > /rant. > > _alex > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev -- Monte Ohrt <mo...@is...> http://www.ispi.net/ |
From: Faine, M. <Mar...@ms...> - 2001-05-17 12:38:06
|
I like xslt but I do believe it seems complex and overly strict. I once tried to do my resume as xml/xslt and gave up after pulling my hair out for 3 days trying to get the page layout right. It wasn't that I couldn't make it work, I just couldn't make it work like I wanted it to work. I got an error on your example: Fatal error: msgtype: error in /home/mfaine/www/xslt_example/form.php on line 18 never seen a msgtype before. -Mark -----Original Message----- From: alex black [mailto:en...@tu...] Sent: Thursday, May 17, 2001 12:20 AM To: bin...@li... Subject: Re: [binarycloud-dev] xslt > I'm interested in seeing some examples. How does this affect the use of > template engines, such as Smarty? Attached. Note that this isn't r2 stuff really, I'm putzing with some ideas. But assuming you have sablot compiled in to php you can run this stuff. It's surprisingly fast. I got _180k_ of html out of it from a 44k xml source + 5k xslt, and that only took 1 second. Most normal documents take in the thounsanths of seconds. Sablot sort of sucks, but 4.1 will solve that. Re: smarty: I'm not going to build in support for smarty, but I should explicitly mention that you can easily build a smarty subclass for TemplateManager. TemplateManager was specifically designed to take any template type, it's a generalized API. But XSLT is so unbelieveably groovy, I'll be building all my code with it. Once you get over some of the little idiosyncracies, you realize how powerful xslt really is. So the short answer is that all release binarycloud 2 modules will use XSLT exclusively. If someone wants to write a smarty subclass for TemplateManager, I'm happy to include it in the release. _alex |
From: Peter B. <re...@f2...> - 2001-05-17 10:18:31
|
<html> At 10:19 PM 5/16/01 -0700, you wrote:<br> <blockquote type=cite class=cite cite>> I'm interested in seeing some examples. How does this affect the use of<br> > template engines, such as Smarty?<br><br> Attached.</blockquote><br> I can't seem to get it to run... and I _have_ got the sablotron extension installed :-)<br><br> <b>Fatal error</b>: msgtype: error in <b>c:/apache/htdocs/xslt_example/form.php</b> on line <b>18<br><br> </b>Any ideas? I'm using PHP 4.01pl1 and the latest sablotron dll on Windows 98, with Apache1.3.12.<br> Peter.<br><br> <x-sigsep><p></x-sigsep> --oOo--<br> Narrow Gauge on the web - photos, directory and forums!<br> <a href="http://www.narrow-gauge.co.uk/" eudora="autourl">http://www.narrow-gauge.co.uk</a><br> --oOo--<br> Peter's web page - Scottish narrow gauge in 009<br> <a href="http://members.aol.com/reywob/" eudora="autourl">http://members.aol.com/reywob/</a><br> --oOo--</html> |
From: alex b. <en...@tu...> - 2001-05-17 05:50:01
|
> I'm interested in seeing some examples. How does this affect the use of > template engines, such as Smarty? Let me expand on this a little, so you understand the reasons: First, the builder classes (yes these are mysterious and not documented, I promise this is coming soon) will all be in the business of generating layout _arrays_ and will not in fact use any presentation code. They will send xml to TemplateManager, with a template location, and TemplateManager will rip the definition (xml) into whatever-you-like (PDF, html, wml, etc) with xslt. So, that means we can use intelligent builder classes to generate these arrays (xml), which can all use the _same_ presentation code. That means you code one form layout, and you only need to code anoher form layout if you have a special/variant form. Everything else is handled for you, down to form element generation. For obvious reasons this is extremely powerful. Now, on top of that, add the ability to output PDF from the same XML that we output html for forms, or a list (html table, or PDF, etc). Whereas before, generating PDFs would really be quite scary, and require lots of separate code - now it isn't scary because of xslt:fo. xslt has some quirks, the syntax is fairly verbose, but my initial reaction was wrong: it isn't so verbose as to be annoying, especially when you look at it in the perspective of a real document, where you see a lot of html, and a bit of xslt. Most of the idiosyncracy comes from the element names, and the _exteme_ strictness of the processor - because everything you write has to be valid xml. After a small period of "ick", I like that a _lot_: if you are using xslt, you are implicitly generating xhtml, and at your option, normal html 4 from the same file. It also means your documents are quite elegant: they are well formed, structurally correct xml docs, and they look nice. Everything is easy to read, because the structure is imposed. I'm still getting use to XPath, and I need to do some experienmentation with xsl:import, but I'm already hooked. Also, this is already a standard, and I think you'll see a huge amount of code generated using it. --- The other thing about XSLT is it doesn't care about the output. You can use XSLT to generate multiple versions of a php file using an XML source, you can use XSLT to output text, csv, you name it. Because of that, it's a fantastic general purpose tool, which we can use for all kinds of tasks. Ok, so how does this relate to entities, and all that? The idea with entities is that they are essentially xml document types: entities are hierarchical structures with nested attributes, and entity definitions can include other entities. Entity definitions include a ton of meta information about each attribute: the basic datatype of the entity, maybe a regex that should be used to validate the data, the attribute name, label, etc. All of this knowledge about the fields in your database is in a clear, structurally sound xml file That means you can reference entities with xpath-like syntax, and quickly build layout descriptions for forms, lists, trees, calendars, etc. Your basic layouts for forms and lists/tables can reside in 2 files. That means you can write entity definitions, and from those you can generate: -metabase xml schemas -forms -lists -displays/layouts with no additional code. if you want to override the "default", then you pass in a template file. I hope everyone understands that concept, and why it is so powerful. If anyone doesn't, please speak up. Instead of building all this markup which is unnecessary, you invest more time in creating entity definitions, rules which govern adding and editing entities (complex attribute relationships), and the system will take care of a lot of the rest of the work for you. All of the binarycloud r2 "data flow" goes thorugh one class (EntityManager), and is validated by the same rules - regardless of whether your input is from an html form, an xml-rpc package, or anywhere else. And because we have all this knowledge about entities nested in the entity declarations, we can make edicated guesses about how the entity attributes should be displayed - so in many cases you can establish a default, and only rarely will you have to build files to overrirde those defaults. /rant. _alex |
From: alex b. <en...@tu...> - 2001-05-17 05:21:53
|
> I'm interested in seeing some examples. How does this affect the use of > template engines, such as Smarty? Attached. Note that this isn't r2 stuff really, I'm putzing with some ideas. But assuming you have sablot compiled in to php you can run this stuff. It's surprisingly fast. I got _180k_ of html out of it from a 44k xml source + 5k xslt, and that only took 1 second. Most normal documents take in the thounsanths of seconds. Sablot sort of sucks, but 4.1 will solve that. Re: smarty: I'm not going to build in support for smarty, but I should explicitly mention that you can easily build a smarty subclass for TemplateManager. TemplateManager was specifically designed to take any template type, it's a generalized API. But XSLT is so unbelieveably groovy, I'll be building all my code with it. Once you get over some of the little idiosyncracies, you realize how powerful xslt really is. So the short answer is that all release binarycloud 2 modules will use XSLT exclusively. If someone wants to write a smarty subclass for TemplateManager, I'm happy to include it in the release. _alex |
From: Monte O. <mo...@is...> - 2001-05-17 04:06:34
|
I'm interested in seeing some examples. How does this affect the use of template engines, such as Smarty? Alex Black wrote: > hi all, > > who here has done anything with xslt? > > I want to make available all the resources I have so people will understand > what reasons we have for using it, why it is so powerful, and why (here we > go) all distro binarycloud r2 modules will use xslt exclusively for all > presentation. > > If anyone's interested, I'll put up some code examples. > > _alex > > -- > alex black, ceo > en...@tu... > > the turing studio, inc. > http://www.turingstudio.com > > vox+510.666.0074 > fax+510.666.0093 > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev |