SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 53

Thread: Xsl

  1. #26
    SitePoint Zealot cholmon's Avatar
    Join Date
    Mar 2004
    Location
    SC
    Posts
    197
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    hmm...on second thought

    there are two ways to do that active nav thing:
    • <navigation active="about">
    • <nav id="about" link="about.php" active="true">



    either way, in order to specify which element to add the attribute to, you have to make sure that you get the correct element. as it stands now, i'm doing this (PHP 4.3.7):

    about.php
    PHP Code:
    <?php
    // ...database stuff

    $doc domxml_open_file('core.xml');
    $root $doc->root();

    // get the first <navigation> element in the document
    list($navigation) = $root->get_elements_by_tagname('navigation');
    $navigation->set_attribute('id''about');

    // ...stick the remaining data in the document and do the transformation
    ?>
    this obviously assumes the first <navigation> element is the one with all the page's navs defined. in order to use the other method, ie <nav id="about" link="about.php" active="true">, I would have to find the <nav> element whose id attribute is "about", then set it's active attribute to "true"...not sure off the top of my head what the code would be, but i'm pretty sure it would be more than the 2 lines i'm using right now.

    i'm sure the performance benefit is negligible...my main concern with regard to this particular issue is readability.

  2. #27
    SitePoint Zealot ohnnyj's Avatar
    Join Date
    Jun 2003
    Location
    California
    Posts
    98
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    cholmon:

    So in how you have structured it so far this is what I am guessing:

    You have one main XML file that has the overall structure of the site laid out (like header, nav, footer, etc.) and have an XSL file that will process that. Then you have another set of XML/XSL files for each page structure that you encounter? Let's say one for a news section, one for an articles section, etc. so that each can be parsed separately.

    If this is the case, do you first create the design to see what it looks like, then transfer this code into the XSL file that will be parsed.

    What I usually end up with is a basic structure like such:

    HTML Code:
     <body>
     	<div id="wrapper">
     		<div id="header">
     	    	<div id="mainnav">
     	        	<ul>
     			 	<li><a href="#"></a></li>
     	        	</ul>
     	    	</div>
     		</div>
     		 <div id="page">
     			<div id="sidebar"></div>
     			<div id="content"></div> 	  
     		</div>
     		 <div id="footer"></div>
     	    </div>
     </body>
    So if I were to create a XSL templating system, would it be best to take this basic structure and put it in a main XSL file like you have done then insert the content I want on each page with a different XML/XSL combonation?

    Thanks,

    - John -

  3. #28
    SitePoint Zealot cholmon's Avatar
    Join Date
    Mar 2004
    Location
    SC
    Posts
    197
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As of now, the only XML file that I've got is core.xml, which is essentially a shell of the data that ends up going through XSLT. I don't have like a news.xml or about.xml...instead I just load up core.xml and append everything that should go into the content section into the <content> element, the transform it with the XSL for whatever page.

    so when about.php is hit, the following files are used:
    • about.php: gathers whatever data is needed for output, sticks it in the xml document (model), and passes the xml to the template (view).
    • core.xml: just the shell of data that every page shares. stylesheets, nav menus, meta tags, javascripts, etc
    • main.xsl: contains the actual structure of the site...all html that each page shares is found in here. it's got a template for displaying the meta tags, navigation, css files, as well as the content
    • about.xsl: includes main.xsl at the top, then defines a template for parsing whatever is in the <content> element, along with any other templates that might be needed to properly render data within the content section of the page


    as for how to actually design the templates, what I do is build the page like normal...just a straight HTML file filled in with dummy data. Then I tear that page apart, putting things like the title bar, nav, footer info, etc in main.xsl, and everything from the content section into a specific xsl file (about.xsl, contact.xsl, index.xsl, etc).

  4. #29
    SitePoint Zealot ohnnyj's Avatar
    Join Date
    Jun 2003
    Location
    California
    Posts
    98
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is exactly what I have been looking for and what I have been wanting to do. I have some of the pieces but was never sure on how to put it all together but this definetely helps. Thank you very much everyone and especially to you cholmon.

    Now the hard part : ).

    - John -

  5. #30
    SitePoint Zealot cholmon's Avatar
    Join Date
    Mar 2004
    Location
    SC
    Posts
    197
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    no problem johnny...what i've got is still in the very early stages, so let me know if you come up with some cleaner way of doing things.

    i'm really interested in using SimpleXML instead of DomDocument, partly to see how performance differs, but mainly to make the code easier to maintain.

  6. #31
    SitePoint Zealot ohnnyj's Avatar
    Join Date
    Jun 2003
    Location
    California
    Posts
    98
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's a question to add to this issue. How should one handle metadata? I came up with the following excerpt:

    HTML Code:
     <metadata>
     	<item>
     		<name></name>
     		<content></content>
     	</item>
     </metadata>
    Someone have a better suggestion?

    Thanks,

    - John -

  7. #32
    SitePoint Zealot cholmon's Avatar
    Join Date
    Mar 2004
    Location
    SC
    Posts
    197
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The way I handle it is very simplistic, which is good for the basics, but more complicated metadata will probably require something different...

    Code:
    <meta>
      <keywords>php, linux, apache, mysql</keywords>
      <description>php on linux with apache and mysql is fun</description>
      <location>Somewhere, USA</location>
      <robots>follow, index</robots>
    </meta>
    you were you talking about HTML metadata right?

  8. #33
    SitePoint Zealot ohnnyj's Avatar
    Join Date
    Jun 2003
    Location
    California
    Posts
    98
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes I was talking HTML metadata, and that seems to be a pretty good structure. I guess I am trying to overcomplicate things.

    However, if you consider the way I presented it, wouldn't this make it easier to translate through the stylesheet. Rather than having to separtely match each meta tag (keywords, description, etc.) you could have something like such could you not?

    HTML Code:
     <xsl:template match="metadata">
     	<xsl:apply-templates select="item" />
     </xsl:template>
     
     <xsl:template match="item">
     	<xsl:for-each select=".">
     		<meta name="name" content="content" />
     	</xsl:for-each>
     </xsl:template>
    I'm just guessing here so set me straight if I am totally wrong.

    - John -

  9. #34
    SitePoint Zealot cholmon's Avatar
    Join Date
    Mar 2004
    Location
    SC
    Posts
    197
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah I see what you're saying...I think I am undercomplicating things more than you are overcomplicating them.

    maybe a slightly modified version of you're idea:
    Code:
    <metadata>
      <item name="keywords" content="php, linux, apache, mysql"/>
    </metadata>
    using this template
    Code:
    <xsl:template match="metadata">
      <xsl:apply-templates select="item"/>
    </xsl:template>
    
    <xsl:template match="item">
      <meta name="{@name}" content="{@content}"/>
    </xsl:template>
    of course that leaves out the http-equiv attribute for things like meta refreshes or setting other HTTP header values. but if you include that as well, you get:
    Code:
    <item name="blah" http-equiv="blah" content="blah"/>
    which looks alot like the actual HTML you're trying to end up with:
    Code:
    <meta name="blah" http-equiv="blah" content="blah"/>
    hmm...not really sure what my conclusion is.

  10. #35
    SitePoint Zealot ohnnyj's Avatar
    Join Date
    Jun 2003
    Location
    California
    Posts
    98
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's exactly the problem that keeps popping up for me. I begin to try and break something down and then it turns back into HTML.

    Consider a script tag as such:

    HTML Code:
     <script>
     	<language />
     	<type />
     	<source />
     </script>
    or

    HTML Code:
     <scripts>
     	<item language="blah" source="blah" type="blah">
     </scripts>
    Once again it become more and more like HTML so I am not sure how to structure it in XML. I'll keep thinking about it and maybe a light will turn on : ).

    - John -

  11. #36
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As language and type are actually optional attributes to the HTML tag it's self, I'd have these as attributes.

    Would make sense though to have the url as a child node of the script node in the sense of it being a single entity in it's own right, also for the obvious use of an external file, the attribute isn't optional

  12. #37
    SitePoint Zealot ohnnyj's Avatar
    Join Date
    Jun 2003
    Location
    California
    Posts
    98
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So optional stuff should be in attributes and all others as their own elements?

  13. #38
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In my view yes, as if you really look at it from the stylesheet point of view yes ? ie

    Your attributes belong to a tag or node/whatever yes ? Well, the only place the attribute data would actually be required would be within the stylesheet template that transforms the tag or node/whatever.

    On the otherhand, if you did have the attributes as a child node of a given tag, you'd require another template within your stylesheet, basically to do what ?

    The attribute (to me) represents data, not structure in the sense that the end result isn't an (x)HTML tag

    Hope you can understand what I'm trying to get at, if not I can maybe attempt to explain things more clearly

  14. #39
    SitePoint Zealot ohnnyj's Avatar
    Join Date
    Jun 2003
    Location
    California
    Posts
    98
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No, I think you got it right. I suppose the best thing to do is to consider each element and see if it would work as a XHTML entity, if not, delegate it as an attribute.

    Thanks,

    - John -

  15. #40
    SitePoint Zealot ohnnyj's Avatar
    Join Date
    Jun 2003
    Location
    California
    Posts
    98
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Now that I have had time to sit down and work with this a little bit it seems as though my XML/XSL files are becoming more and more complex. One thing that I am having particular difficulty in is trying to determine the overall structure of my XML document.

    I liked cholmon's as a basis for it gives a basic structure to the design but what should I do about more specific things. For instance let's say that I have a <content></content> block that will always be populated differently depending upon what I want to show up on a particular page. What I tried to do was gather ideas from varies posts made here to come up with a combonation of XML files. Would it be advisable to take the basic structural XML file and then when needed use a different XML file to plug-in to the content section when needed?

    What I have done is create a news.xml file that would serve as my blog entry file based roughly on the outline from the previous page. Then I could implant this XML file into the basic structural one (under the content section). I could do the same for other things, such as comments, articles, etc.

    Here is how I have structured it so far:

    HTML Code:
     <?xml version="1.0" encoding="iso-8859-1"?>
     <page>
     	<title></title>
     	<metadata>
     		<meta>
     			<name></name>
     			<content></content>
     		</meta>
     	</metadata>
     	<stylesheets>
     		<css></css>
     	</stylesheets>
     	<scripts></scripts>
     	<navigation>
     		<link>
     			<title></title>
     			<name></name>
     			<target></target>
     		</link>
     		<link>
     			<title></title>
     			<name></name>
     			<target></target>
     		</link>
     	</navigation>
     	<content>
     		<sidebar orientation="">
     			<feature type="">
     				<headline></headline>
     				<navigation>
     					<link>
     		    		    <title></title>
     		    		    <name></name>
     		    		    <target></target>
     					</link>
     				</navigation>
     			</feature>
     			<feature>
     				<headline></headline>
     				<list></list>
     			</feature>
     		</sidebar>
     		<news>
     			<entry id="" permalink="">
     				<title></title>
     				<subtitle></subtitle>
     				<summary></summary>
     				<author></author>
     				<link>
     					<title></title>
     					<name></name>
     					<target></target>
     				</link>
     				<published></published>
     				<modified></modified>
     				<text>
     		    	    <paragraph></paragraph>
     		    	    <paragraph></paragraph>
     				</text>
     			</entry>
     		</news>
     	</content>
     	<copyright></copyright>
     </page>
    Have I made it too complicated? Does it need more elements, should I get rid of some? Any ideas on a better structure? And is it permissable to do as I have done in having elements w/the same name under different children (i.e. having a navigation element under the the root element page as well as under the feature element within the content sidebar)?

    Thanks,

    - John -
    Last edited by ohnnyj; Jul 16, 2004 at 18:05.

  16. #41
    SitePoint Member
    Join Date
    Jul 2004
    Location
    Norway
    Posts
    13
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    About having values as attributes or not in xml. On trick I learned was to set everything that was suppost to show on screen as elements and everything else as attributes.

    Examplea href="xmlAttribute">xmlElement</a>

    Edit: Yes I know that my link example earlier in this thread not follows this. Sorry Links should be described as this with xml:
    Code:
    <link target="..." title="...">linkname</link>
    the reason I posted it wrong was due to some limitations in xquery with Yukon that made it really hard to generate attributes where we wanted them, so therfor we used the style i first described.

  17. #42
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Would it be advisable to take the basic structural XML file and then when needed use a different XML file to plug-in to the content section when needed?
    I'm not sure that this would be the best approach ? What I would do is stick to a set number of 'known' tags that'd represent your content, and then have seperate stylesheets to transform the content differently, if your problem is a structural one ?

    ie It would be easier to manage (from a Model point of view) your defined number of tags this way, rather than having to create various tags for a specific set of data ?

    It would then be a case of the View selecting the required stylesheet, which shouldn't be too difficult anyways

    Note : Remember that once you've transformed one set of XML data with a stylesheet, the result is an object yes ? Well, not only can you pass in a file or string representation of your data, but you can also pass in the object (representing a portion of transformed data) to another stylesheet

    Hope that last paragraph makes sense

    Me on the otherhand have been thinking that as far as content goes, I would have a tree structure database table to represent the overall content hierachy ?

    Then instead of having a seperate db table for news, articles, etc I would instead have one table only which would accommodate all the content required.

    For my uses this is fine, though the solution has problems in it's own for example, multiple paged articles wouldn't be ideal

    I'm thinking of this approach as after looking at the Optimistic Lock pattern (M Fowler) and related Lock patterns, it was suggested in context that a single ID to represent all content (to me, one db table) would be better to work with

    So instead of an INT PK for a news table, likewise for an article table, I'd have a 32 character STRING PK instead ?

    Hope I've helped anyways ?

  18. #43
    SitePoint Zealot cholmon's Avatar
    Join Date
    Mar 2004
    Location
    SC
    Posts
    197
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    What I would do is stick to a set number of 'known' tags that'd represent your content, and then have seperate stylesheets to transform the content differently, if your problem is a structural one ?
    This is the main issue nagging me at the moment, and johnny as well it seems. When I first started using this method, all I really wanted to do was have the same basic functionality of Smarty, mainly with regard to variable substitution. In Smarty, you just create a Smarty object, assign a bunch of variables to it, then call the display() method with whatever template you want. As far as I know, there's no mechanism in Smarty for restricting the template to a fixed set of variable names, as an XML schema or DTD would if the templates were XSLT instead of the Smarty proprietary language.

    The one site I'm maintaining now that uses this method behaves in much the same way as Smarty, and the more I think about it the more I think it may behoove me to come up with some sort of all-encompassing schema for the <page> document in its entirety. The nice thing about being able to shove whatever elements you want into the <content> block is that allows for some fairly quick, albeit unorganized, PHP. The downside is obviously that each XSL template is going to be proprietary to each page. A user management script, for instance, may use the following code in the <content> block:

    user_view.php
    Code:
    <users>
      <user uid="123" gid="3" username="cholmon">
        <firstname>Drew</firstname>
        <lastname>King</lastname>
        <last-login-ip>12.34.56.78</last-login-ip>
      </user>
    </users>
    This makes the XML pretty straight forward, but this is just for this user management script. The general issue seems to allow for 3 ways to attack the problem:
    • No formal schema for the elements inside the <content> block. Easy to make up your own elements for each page, but also easy to end up with an enormous mess of made-up-on-the-fly tags.
    • A single formal schema for <content> (and thus the entire <page> document?) that is flexible enough to allow for the representation of a majority of presentation-type data structures. This may make it trickier to write the code to populate the model though.
    • A single schema for the outer <page> document (ie, core.xml) and a seperate schema for each page's <content> block. But then you'd end up with a ton of schemas for any given app.

  19. #44
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, I can see your predictament now

    But in saying that though, from the 3 options you have, personally I would go with the third option ?

    I would say this as even though you may end up with a load of schema's for any given application, these would be easy enough to maintain and modify if required ?

    Modifying these schema's I'd think would alter your data representation yes ?

    Well, wouldn't it long term, be better to maintain these, rather than having to make modifications to scripts and possibly templates ?

    The first option is not really a viable one anyway, as I think you do need something to validate your XML

  20. #45
    SitePoint Zealot cholmon's Avatar
    Join Date
    Mar 2004
    Location
    SC
    Posts
    197
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    The first option is not really a viable one anyway, as I think you do need something to validate your XML
    Absolutely...option #1 is definitely not something I want to continue using. I'm using it now b/c it was the quickest way to get the code functioning. At the beginning, my main concern was in getting the XSL to work right, but as the app has grown I've found myself (re)*-inventing my own wheel several times.

    And given the complexity that would result from Option #2, I'd agree that Option #3 definitely looks like the best choice among the group.

  21. #46
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yer Would be cool if you have a tool to create, modify and store your schema's as well ?

    If so, then just about anyone could manage this, given enough (minimum) training if they're not aware of the issues.

    Also means that they are no where near the actual 'guts' of an application, where they could totally screw things up

  22. #47
    SitePoint Zealot cholmon's Avatar
    Join Date
    Mar 2004
    Location
    SC
    Posts
    197
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Indeed. And if it could be packed up all nice and neat, it might be easy enough to deploy for pretty much any kind of web app. I guess that would classify it as a framework...provided alot more planning and sweat was put behind it.

    I kind of hesitate to say that though, particularly since at this point it just focuses on the model and view of a potential MVC framework. I want to keep the whole system as lightweight and easy to extend as possible, without too much wheel re-invention . It seems that too often frameworks grow and mutate to fill in as many gaps in functionality as possible, and performance & flexibility suffer at the expense of ease-of-use.

  23. #48
    SitePoint Zealot ohnnyj's Avatar
    Join Date
    Jun 2003
    Location
    California
    Posts
    98
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey guys:

    I have been reading your comments and suggestions and agree with the whole idea of modularity. It only seems logical to have separate XML files/structures for the content block so that one can easily extend its use and not worry about the main structure being compromised. Plus it helps to get the project rolling as if one were to try and sit down and come w/every possible element they may need in the content area it would most likely never get started.

    On a side note, I wanted to share some of my findings after doing a little Googling. I found a nice program that helps in creating all sorts of XML files called XMLSpy by Altiva software. The actual product is rather expensive but they do have a free home version that has a lot of the functionality I need right now. This includes an Intellisense like auto-completion feature, and automatic tranformation of an XML file w/XSL(T). Go over to http://www.altiva.com, it has been a great tool so far.

    Plus they included some great example XML/XSL(T)/XSD files. One in particular caught my eye as it is basically trying to do much of what we have been doing. Of particular interest is a file called blocks.xml which is has a series of content blocks with different stuctures that are each defined by their own id. They then have their XSL file process each XML document and open up this blocks.xml to find out which content block to insert. This might be a good idea for different navigation structure (horizontal/vertical), different sidebars, muli-columnar layouts, etc. It is all about extensibility and modularity which I am all for. Their XSL file was a real eye-opener in terms of how to process an entire site structure (one negative, though is their lack of complete standards compliance in the XHTML tags they use, but for the most part it is a great resource).

    Here is the blocks.xml file for your perusal:

    HTML Code:
     <?xml version="1.0" encoding="UTF-8"?>
     <!-- edited with XML Spy v5 beta 4 U ([url]http://www.xmlspy.com[/url]) by Alexander Falk (Altova, Inc.) -->
     <?xmlspysps blocks.sps?>
     <blocks xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="site.xsd">
     	<block_instance>
     		<id>exampleblock</id>
     		<pagefragment>
     			<header>
     			  This Is an example Block of content that can appear on any page in the site by including a pagefragment tag with an idref of 'exampleblock'.
     			</header>
     		</pagefragment>
     	</block_instance>
     	<block_instance>
     		<id>sample</id>
     		<pagefragment>
     			<br/>
     			<para>Welcome to the Example Site!</para>
     		</pagefragment>
     	</block_instance>
     </blocks>
    As you can see they use different block structures depending upon what they wish to display. This way I suppose you could have one file that contained such things as a user authentication block, a blog type block, etc. each w/their own unique id that you reference in your XSL(T) file to display the right one.

    Here is a clip from their XSL file to see what I mean:

    HTML Code:
     <!--*************************************************-->
     <!--************************handlepagefragment************-->
     <!--*************************************************-->
     	   <xsl:template name="handlepagefragment">
     	   <xsl:param name="blockid"/>
     		   <xsl:for-each select="document('blocks.xml')">
     				 <xsl:for-each select="//block_instance">
     					 <xsl:choose>
     						 <xsl:when test="id=$blockid">
     							  <xsl:apply-templates select="pagefragment"/>
     						 </xsl:when>
     					 </xsl:choose>
     				 </xsl:for-each> 
     		   </xsl:for-each>
     	   </xsl:template>
     <!--*************************************************-->
    They have created a kind of function like architecure calling this template whenever they need to display certain parts of their documents.

    For instance their home page looks like such:

    HTML Code:
     <?xml version="1.0" encoding="UTF-8"?>
     <!-- edited with XML Spy v5 beta 2 U ([url]http://www.xmlspy.com[/url]) by Robert Gillis (Altova, Inc.) -->
     <!DOCTYPE dictionaries SYSTEM "examplesite.dtd">
     <main xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="site.xsd">
     	  <idref>welcomepage</idref>
     	<pagetitle>welcome</pagetitle>
     	<content>
     		<pagefragment>
     			 <pagefragment idref="welcome"/>
     			 <pagefragment idref="sample"/>
     			   <pagefragment idref="mysitelogo"/>
     		</pagefragment>
     	</content>
     </main>
    As you can see they sturcture each page so that they have a unique id they can reference in their XSL file and then display their content by referencing pagefragments with specific ids.

    One could easily take this to a PHP realm rather than a pure XML based site. Rather than having a predetermined XML file created it could be generated on the fly (especially once PHP 5 gets going).

    I hope these pointers and examples give you some help as they have me and once again I heartedly recommend you check out the XMLSpy program unless you already have something better.

    - John -

  24. #49
    SitePoint Zealot cholmon's Avatar
    Join Date
    Mar 2004
    Location
    SC
    Posts
    197
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for those examples johnny. I have heard of XMLSpy before, but I haven't given it a try yet...I think I might play with it some in the next few days.

    The whole idea of a block-centered layout makes me think of the FuseBox architecture, which has a PHP port (originally written for ColdFusion), or Tiles for Java Struts. Both Fusebox and Struts are full-fledged web application frameworks though. I probably shouldn't even be writing about those technologies, as I've only seen them in passing, but what I gathered from my bird's eye view was the same idea that you're talking about. Basically, you define the overall structure of the site in a central file, using blocks (or tiles in JSP) to place content elements wherever you need them on the page. There are other support scripts and config files that determine which blocks to load, when to load them, and where they belong.

    I've got to wonder how much of this has been done before with PHP and XSLT. There is a chance that we're trying to solve a problem that has already been solved, perhaps in a similar fashion. But the cool thing about attacking this problem from the ground up is that we are seeing the problem(s) first, then finding the solution. As opposed to learning the solution that someone else has come up with, then trying to figure out what on earth the problem was.

  25. #50
    SitePoint Zealot ohnnyj's Avatar
    Join Date
    Jun 2003
    Location
    California
    Posts
    98
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oops, the link to the software is at http://www.altova.com not altiva. Sorry about that.

    I too have heard of these other templating/architectural technologies such as Fusebox and Struts but like you have never tried to research them any further.

    I like your point, if we don't know that this has already been worked on we can try our own design which might actually come out even better. Of course you can also look at the other side, if someone had already tried to design such a framework, we could learn from their mistakes.

    However, it is my assumption that it has never been undertaken or if it has, that it has not been finished nor released to the public. I have scoured the Internet trying to find anything related to what we are doing without finding anything conclusive.

    Regardless, I think that if it can be done it will be a great framework.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •