SitePoint Sponsor |
|
User Tag List
Results 126 to 138 of 138
-
Apr 16, 2005, 14:34 #126
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Gathering data for a page in a structure which mirrors the page layout can make it more awkward to share.
Now, this leads to this problem... What or how do you determine if one composite or another one for that matter, isn't interested in knowing that common data? For example, as you've pointed out, the HEAD would need to know about a title, but not so the FOOTER.
Please continue McGruff, as you are going somewhere with this
-
Apr 16, 2005, 15:28 #127
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
That could be handled by Dreamweaver libraries.
Suppose for example you wanted to use the same application on the command line. You'd print the data in paragraphs not blocks.
However I think the cases you mention would be better handled with a separate Presentation layer. If you needed to drive a vector based chisel to carve the output in to stone tablets you would need such a thing as well.
I also think you miss mentioning outputting realistic options like PDFs where a hierarchy is eqully beneficial.
Often you'll find that bits of data cut across page elements:
I started off by wondering if information about page structure was leaking out of the presentation layer. What I meant to say was is it extending too far into the view.Christopher
-
Apr 16, 2005, 15:31 #128
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Selkirk, I am interested to know if you plan to use a hierarchy of controllers that pass the Views back up through them, or if they create a hierarchy of Views that the root controller then renders?
Christopher
-
Apr 16, 2005, 16:34 #129
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
The CLI example was intended to illustrate some design consequences but I also think it's of practical use. With a backup program, it would be easy to adapt the same essential core for use with either a web interface or shell.
Originally Posted by arborint
-
Apr 16, 2005, 16:59 #130
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
or if they create a hierarchy of Views that the root controller then renders?
At this point, the View already has it's HTML fragment composed with whatever Model(s) (their data) it uses, and the composite takes this composed HTML fragment and appends it to it's parent composite's HTML fragment.
This goes on until you reach the root composite, if that's any help?
-
Apr 16, 2005, 17:13 #131
- Join Date
- Jan 2005
- Location
- Sydney
- Posts
- 43
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I can see what McGruff is on about.
There should be a way to call the model and pass it to the view without any defining structure, but I have yet to see it. I don't know if we should break a rule here or there to make it easier to work with.
On the other hand, I was thinking about the XML set up that Livingston posted about earlier and thought about using PHPTAL for this.
Code:<page> <title tal:content="path content/blogs/title"/> <content> <blog tal:action="latestBlogEntries"/> </content> </page>
Code:<page> <title>Latest Blog Entries</title> <content> <blogs> <title>Latest Blog Entries</title> <blog> <title>PHP....</title> <text>PHP do da do....</text> </blog> </blogs> </content> </page>
Would this break a rule and if so, is it justified?
-
Apr 16, 2005, 18:51 #132
- Join Date
- Sep 2003
- Location
- Glasgow
- Posts
- 1,690
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by dylanegan
PHP Code:class FooViewData
{
// vars used by the template
var $foo; // (string)
var $bar; // (string)
var $list; // (object) - an iterator
function setData()
{
$something =& $this->_someKindOfDomainObject();
$this->foo = $something->getFoo();
$this->bar = $this->_request->getBar();
$this->list =& $this->_someKindOfDataAccessObject();
}
function &_someKindOfDomainObject()
{
include(..etc..);
return new SomeObject;
}
function &_someKindOfDataAccessObject()
{
include(..etc..);
return new SomeObject;
}
}
class FooHtmlPrinter extends FooViewData
{
var $_request; // (object)
function FooHtmlPrinter(&$request)
{
$this->_request =& $request;
}
function print()
{
$this->setData();
include('path/to/foo_template.htm';
}
}
In practice, it would be slightly more complicated since data might not be available. The setData() method could return true/false, and this would have to be checked in the print() method. You might even have something to undo: the simple act of reading data can occasionally change the model.
Let's say the Foo html view uses a shared header. Where did it go..? On the application side of the boundary, there is no such thing. Just data.
Perhaps I'm missing something, but this seems a whole lot simpler than what I've understood from some of the hierarchical systems being described (although I haven't been looking at actual code). Some hierarchies simply don't exist on the application side of the boundary. Some do: but that's because they are genuine data relationships rather than relationships between the parts of a page layout - eg a list of forums with nested lists of boards.
I don't know if we should break a rule here or there to make it easier to work with.
-
Apr 16, 2005, 19:05 #133
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
There should be a way to call the model and pass it to the view without any defining structure, but I have yet to see it.
Let's say the Foo html view uses a shared header. Where did it go..? On the application side of the boundary, there is no such thing. Just data.Christopher
-
Apr 16, 2005, 19:50 #134
- Join Date
- Jan 2005
- Location
- Sydney
- Posts
- 43
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Well I do believe I wasn't very clear too. I find it hard to communicate an idea through a medium instead of in person, so sorry for that. As for structure definition I was referring to the way I was passing an XML doc to the View, where another way would be to pass each XML block as you go along.
What I am going to end up using is something similar to the example I posted before. I think it's a simpler controller and is easy enough for a non-technical person to understand. I will let you know how it works out.
-
Apr 16, 2005, 21:41 #135
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
So the first stage is to take the input request and determine which portions of the tree to render. This is done by traversing the tree from the root to a leaf. This path from root to leaf is called the command path or the focus path.
The next stage is to build the composite view. For this, we walk the focus path from the leaf node back to the root. At each node we assimilate the view that is associated with that node. In addition, we can collect the children of the node that didn't receive focus, but that can participate in a composite view. These extra children are called 'active' children.
On this page, the articles, books, and blogs children are NOT active children. They can receive focus (When the user clicks on those tabs), but they do not participate in the composite view otherwise. You could imagine that it would be possible to have another organization of this page where those branches where simply hidden via the DOM and the tabs implemented by javascript. In that case, those branches would be considered 'active' because they would be rendered to the view.
As we move back up the line of focus, if we ever reach a point where our composite view cannot be a child of another view, then we stop and render it. This allows child trees to override layout set by a higher level node.
The reason we go from bottom to top when composing the views is purely for performance. Imagine that a lower level view overrode the master layout. It would have been a waste to instantiate the view object associated with the master layout too early. By traversing from the leaf to the root with our ViewComposer, we can be assured of instantiating only the view objects that we are going to actually be rendered. It does make building the composite view more difficult, however, this shouldn't matter to framework users.
Some nodes have children that can neither receive focus, nor activation. During the focus path building stage, events are able to forward focus to another part of the tree. When this happens, the focus path is re-drawn from the root to that node. Thus, nodes that can't receive focus based on direct user input can receive focus based on programmatic control. This is good for error messages, exceptional conditions, and wizards.
Sounds complicated, huh? My hope is that it won't be in actual practice. I'm still implementing it.
-
Apr 17, 2005, 00:07 #136
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Sounds complicated, huh?
I'm wondering a couple of things. One is whether this scheme is any better than the traditional Front Controller dispatching an Application Controller where you explicitly specify the tree you mention.
Second, is whether WACT is going towards the Ruby on Rails "automatic transmission" style that seems to be the rage? If what you describe you are building sits on top of a basic controller architecture and can be used both ways, that would be interesting. I guess I'll just have to wait and see.Christopher
-
Apr 17, 2005, 01:24 #137
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I think Ruby on Rails is recieving way too much attention and hype at the moment, it needs to settle first but that's my view only.
Imagine that a lower level view overrode the master layout. It would have been a waste to instantiate the view object associated with the master layout too early.
You could also I suppose, use a completely different parent template based on these actions, and let the recursion begin all over again, which does offer some surprising developments
Looking forwards to seeing more of your ideas Selkirk.
So the first stage is to take the input request and determine which portions of the tree to render.
http://www.isis.vanderbilt.edu/publi...Tool_Suppo.pdfLast edited by Dr Livingston; Apr 17, 2005 at 03:27.
-
Apr 17, 2005, 05:10 #138
Originally Posted by Selkirk
If ViewComposer was building a XSLT, each node would be providing a <xsl:template>, and if one provides <xsl:template match="/">, its complete, and traversal can stop.
Bookmarks