View-Based Design

[Eric_Ryk]

I came up with an idea that I'll call view-based design for simplicity. The basic idea is that when a page is loaded it knows what the final output, in general, should look like. Usually on websites this is mostly true, with a few exceptions as to the page's actual content, which I'll address as well. So lets say you have all the different things that the website needs to display in some form of an array or list or whatever you want it in (I used a composite structure). You loop through every "node" and you see if it is static, meaning the same on every page in the website, or dynamic, meaning that it can change. If it's static you don't do anything, if it's dynamic you create a controller to make the necessary model needed for the view node. Then once everything has been generated and assessed, you display all the nodes by looping through once more.

Really I just want to know if this violates any design rules or if it could be improved or if you think it's impractical. Thanks for reading though.

[448191]

I don't really see how that would work. Maybe you could share some example code, or even better, a class diagram?

The general idea is not per se bad, but I don't think it can be a whole new paradigm in it's own right.

The part I don't get is: "The basic idea is that when a page is loaded it knows what the final output, in general, should look like."

How? You'll need controllers and the model... So I guess I don't really see how to accomplish this without a 3-tier or MVC structure... :-\

If you use a decentralized design with single page controllers for each page (i.e edit.php, select.php etc etc) you could at least avoid a php front controller (apache is your front controller) but that could easily become inflexable, hard to manage and extend. But even then you'll need business logic so I think it's pretty much impossible to start with the view. Unless maybe when you consider something like an XML file which transforms (Xslt) part of the view and consider classes modifying this file presentation logic, not business logic...

I don't recommend a decentralized design, if only for code management.

[Eric_Ryk]

I packaged it up in a ZIP. So you can take a look at it here: [url=http://digishout.com/TOM.zip]Zip File[/url]

It is a centralized design though. Just wondering, when you have a website do all your pages look radically different? Because mine usually share some things like a side-bar, or head navigation. The point of this is that web pages generally share some features. So what I've done is created an XML file (I've dumbed it down a bit for simplicity in the ZIP) that has basically the page layout in tpl files.

A builder class takes this and turns it into a composite then returns the root node of it.

[448191]

[quote author=Eric_Ryk link=topic=120063.msg492686#msg492686 date=1167328350]
I packaged it up in a ZIP. So you can take a look at it here: [url=http://digishout.com/TOM.zip]Zip File[/url]

It is a centralized design though. Just wondering, when you have a website do all your pages look radically different? Because mine usually share some things like a side-bar, or head navigation. The point of this is that web pages generally share some features. So what I've done is created an XML file (I've dumbed it down a bit for simplicity in the ZIP) that has basically the page layout in tpl files.

A builder class takes this and turns it into a composite then returns the root node of it.
[/quote]

Sure, I call them Xhtml 'frames' (confusing, yes). I attach dynamic parts to it. What I'm missing is how you adress composing the dynamic parts. It's probably in your code, but I don't see it at first glance.

[Eric_Ryk]

[quote author=448191 link=topic=120063.msg493074#msg493074 date=1167379562]
[quote author=Eric_Ryk link=topic=120063.msg492686#msg492686 date=1167328350]
I packaged it up in a ZIP. So you can take a look at it here: [url=http://digishout.com/TOM.zip]Zip File[/url]

It is a centralized design though. Just wondering, when you have a website do all your pages look radically different? Because mine usually share some things like a side-bar, or head navigation. The point of this is that web pages generally share some features. So what I've done is created an XML file (I've dumbed it down a bit for simplicity in the ZIP) that has basically the page layout in tpl files.

A builder class takes this and turns it into a composite then returns the root node of it.
[/quote]

Sure, I call them Xhtml 'frames' (confusing, yes). I attach dynamic parts to it. What I'm missing is how you adress composing the dynamic parts. It's probably in your code, but I don't see it at first glance.
[/quote]Tpl_Dynamic_Decorator makes a generator and calls its act method, which will start the rest. In this version not really much is happening so it's a pretty simple example.

[ShogunWarrior]

Is this all done at runtime though? I'd worry about the performance/memory hit of increasing layers of abstraction, especially text-based  (such as XML-parsing) operations.

[448191]

Ok, I attempted to reverse engineer a class diagram to make sense of it all:

[img]http://home.orange.nl/lekkage/img/ClassDiagram1.gif[/img]

I'm probably missing some stuff, it's a bit much work to review and link all the code, especially since the function of some classes aren't that transparant.

Anyway, I do have some critique.

You're not following a strict interface. An example [Tpl_Component]:

[code=php:0]
  public function display()
  {
 
  }
[/code]

Default behaviour that does nothing serves no purpose. Instead declare abstract.

This is an implementation of display() [Tpl_Composite]:

[code=php:0]
  public function display()
  {
      foreach($this -> children as $child)
      {
        $child -> display();
      }
  }
[/code]

This is NOT, why is it even there? [Tpl_Dynamic_Decorator]
[code=php:0]
  public function display()
  {
      parent::display();
  }
[/code]

That's what you get when using multiple levels of inhertance: responsibilties become unclear and the interface hard to manage an implement. Tpl_Decorator need not inhherit from Tpl_Component, if I'm on track on what it actually does (responsebilities are still a little vague to me).

Overall you need to rethink the structure I believe.

I do however better understand how you plan to create dynamic content, but I think you're a bit confused about the processing.

Dynamic parts of the view rely on controllers and business logic to generate their content. True that one can use some of the same controllers for different generators (that reflect a certain request), but at what point are you going to translate this request into actions? I foresee a scenario with a lot of repeating logic.

Only way around that I can think of is to execute business logic and set the processing to a status of 'complete'. But that effectively makes this no different from a more traditional design, except you have to check for the status every time you need to render a dynamic part.

The view isn't at the core of an application, the business logic is. The view just reflects the state the applciation is in. You will need to create a state, then you can determin how the view should reflect that.

[Eric_Ryk]

I must say, this is exactly the type of thing that I was looking for. You hit the nail on the head with the class diagram.

Some quick explaining about the decorator portion and my implementations where I just use the parent, I'm simply leaving a quick trail for me to go back and edit. Now onto the part about it inheriting from the component. What I'm doing here is making the composite as a whole indifferent to whether its dealing with a decorator or not. This way I'm able to make it have a parent class and work like the rest.

Now on to the idea of a controller and business logic. When I implement this (should I) I would create a dynamic composite node, rather than a leaf node. This would call upon the generator that would either act as a controller or call upon a controller that would handle the basic page request.

I'm not really looking for credit for an idea, I just want to know if it sounds workable. When I gave it the name view-based design I wasn't looking at developing some whole new system, just trying to find something that works for me. In your first post I got the impression that you thought I was trying to come up with some new practice of programming for all.