Re: Re: OOP vs procedural

The great thing about server side XSLT transformations is the XSL parts must be totally w3 compliant but that does not mean to say the entire template does, only that which you parse through the processor. In answer to your questions: 1)The browser will read HTML/XHTML and will act as all other browsers do. XHTML is just a more "strict" version of HTML. 2)Your application generates XML, which as you said has nodes with data. Before you send that to the browser you send your "xml" to a server side XSLT processor, Sablot or Saxon or something. At the same time you also pass an XSL style sheet to the processor. It takes the XSL and XML and uses them to build a dynamic page. Now, the xsl stuff consists 3 parts: xslt: transforms xml docs xpath: defined parts of an xml document xsl formatting: formatting xml documents When you combine these with your web language such as html or wml you can build a "stylesheet" which can dynmically transform dynamic xml data into viewable pages. You can look at flash as a version of XSL if you want to, it simply transforms XML into readable data 3) Browsers are always going to be rewritten but they dont need to do anything to cope with this type of thing 4) A browser can read raw xml as its just a text document, to make anything meaningful you have to use other stuff! jim. "Info@Best-It" <info@best-it.biz> wrote in message news:BADD589C.5BB5%info@best-it.biz... > I've heard a lot that XML is taking over. Is the browser going to read some > kind of HTML or straight HTML. Take FlashMX for instance, you can build a > movie which is essentially an application driven by XML. But the XML is > like a Database with nodes instead of records. This can be dynamically > generated and read by the Flash movie, but because it's flash. If you took > that same flow and created an app that had a browser for the front end > instead of flash player, how would you get the browser to understand what it > needed to display? Are browsers going to be re-written? - Most likely my > thought process is off track. Mainly I don't understand how a browser can > read XML? > > R/T > > on 5/6/03 11:17, James at james@globalvision.com wrote: > > > Depends on your view point. I think PHP was never originally intended to be > > written in OO but I favour it for my stuff and I think a lot of other people > > do too, including (rather amazingly :) the PEAR lot who are rapidly becoming > > what CPAN is to Perl. One of the things to think about is the upcoming > > release of version 5 which is going to see a huge leap in the OO part of > > PHP. There is masses of new features such as private, protected, > > namespacing to name a few. If you intend to a) stick with php and b) build > > complicated "application frameworks" then consider the fact that they are > > intent on pushing out a new version of PHP with a much better object > > approach and with this in mind youll see a lot more object based > > developments. > > > > Regardless of your approach with OO or libs I think the 3rd style which is > > _MUCH_ more important is the development of systems with data independence. > > Creating systems which run entirely in XML is the future. The days of hard > > coding HTML into your code is going to change. Seperating application > > logic/business rules is so much more important when your working with large > > scale apps. Running server side XSL styles through your app's XML output is > > what you should aim for. Given that the web is ever expanding and youll see > > new display langauges for all sorts of new fangled internet gadgets youll > > regret not doing it! > > > > jim > > > > > > "Info@Best-It" <info@best-it.biz> wrote in message > > news:BADD4609.5B9D%info@best-it.biz... > >> Between these 2 styles of writing PHP which is better usually: > >> > >> C-style, using include files containing paths to libraries? > >> > >> Object Oriented: everything is structures with class files? > >> > >> Thanks, > >> /T > >> > > > > >