Well, I'm not quite sure I get the whole idea, but:
- - The content of the session is, if not configured otherwise, included in the XML response document, so that ie. you can access your user information from a template. Having <xsl:if test="/response/session/registereUser"> being true if a registeredUser object is inside our session.
- What ever is in the SESSION that represent the page the user is trying to view is hence also accessible.
- Verifying that the user can view the resource is also doable with <xsl:if test="/response/session/registeredUser/level > /response/session/page/level">
But, except for point 1, this breaks the whole framework's idea!
When I said
This example is fairly simple, it all ties together a bit differently in the whole framework.
here's what I meant and how it actually happens:
Code: Select all
<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:import href="layout/layout.xsl" />
<xsl:output method="xhtml" encoding="iso-8859-1" indent="yes"
omit-xml-declaration="yes" />
<xsl:template match="/">
<xsl:call-template name="makeLayout" />
</xsl:template>
<xsl:template match="response">
<!-- Actual transformation for your page happens here -->
</xsl:template>
</xsl:stylesheet>
So let me explain what happens here:
When you <xsl:import href="layout/layout.xsl"> you actually import your page's layout (menu's may they be conditional or not, but you code it only once). This file, in many cases, contains one simple <table> with 3 rows, the second one having 3 cols, so that you get the basic top, bottom, left, right and main section of your website's layout. The top, left, right and bottom in turn <xsl:import ..> the content for these parts, while the main part contains the, in the above code, missing, <xsl:apply-templates />.
The templates that you want to be applied, you have to define them in the actual file you are editing, like the above code, let's say user/prefs.xsl which contains the form for user preference management.
First advantage, I, ihmo, see here, is that your layout and page are clearly seperated and that way easier maintainable.
Now to form validation:
the following code is a part of what would replace the <!-- Actu... here --> in the above example:
Code: Select all
<table>
<form action="prefs?mod" method="post">
<xsl:if test="errors">
<tr>
<td colspan="3"><b style="color:red">You didn't fill out the form correctly</b></td>
</tr>
</xsl:if>
<tr>
<td> Name:</td>
<td><input type="text" name="dataїname]">
<xsl:attribute name="value"><xsl:value-of select="prefs/name" /></xsl:attribute></input></td>
<td><xsl:if test="errors/name">
<b style="color: red"><xsl:value-of select="errors/name" /></b>
</xsl:if></td>
</tr>
<!-- snip -->
</form>
</table>
As you can see, only the form and it's validation result are showed here (showed! this our view, no logic here; while you could add JS to ease with Client-Side validation).
The validation itself is done in our object prefsForm that get populated by $data[] and the auth requirement is done in the controller, /user/prefs. I use rewrite Rule to get nicer URL, like /user/prefs?mod gets rewritten by apache to /user/prefs.html?action=mod...
So our prefs.html would for instance have an include("auth.inc"); that would be some authentication verification, let say a simple:
Code: Select all
if(!isset($_SESSION["registeredUser"]))
HttpResponse->redirect("/user/login");
the redirect method of our HttpResponse object is some nice headers being sent to the client, temp moved and location, and then exits;
The controller, in our mod case, simply:
Code: Select all
require("auth.inc");
$prefs = new PrefsForm();
if(isset($_POST["data"])) {
$prefs->setData($_POST["data"]);
if($prefs->validate())
$_SESSION["registeredUser"]->updatePrefs($prefs);
} else
$prefs->setData($_SESSION["registeredUser"]->getPrefsData());
$HttpResponse->add($prefs);
$HttpResponse->xsltr("user/prefs.xsl");
So this would be a bit more complex example. I haven't talked about the PrefsForm() class that extends a frameworks' own HtmlForm class that implements utilities method for populating, validate and such our forms
But that way you have a clean separation between Model, View and Controller.
Again, in this case the View is our prefs.xsl, Controler is prefs.html and Models are $PrefsForm, $registeredUser... objects.
I hope this clarified the whole thing a bit (even) more. The thing you should try to grasp is the MVC paradigm. Which is mainly what I am trying to implement in the framework. I choose XSL, because I believe XML is usefull at some point or another and because its more a technology I'd like to rely on than other "funky" template engines...
But our discussion brought me to the point that I realised I should automatically add the url the user requestes into the HttpResponse... It could be usefull, for say the left.xsl template to decide what context sensitiv menus to display.
Hope this helped to get my point over to you, don't hesitate to continue pushing yours that, even if I got to the point it doesn't follow the Model 2, it will help me bring the FrameWork to the most out there, rather than just for the solutions I am working on right now.
But the FrameWork is about to change, depending on PHP5, user reaction's on the pre-release I will make in a few weeks and people (including mine) requierement in the future...