SitePoint Sponsor

User Tag List

Results 1 to 19 of 19
  1. #1
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    comments on mini-framework

    Hi all, this is kind of the way I usually build sites, I just got around to putting it together as a "framework". I'd love to get some feedback on the whole thing. Please download and try it out! At this point, it's just an example of how the template engine can work, along with an action chain. It uses the new WACT DataSource for a lot, so you might want to check that out!

    -matt
    Attached Files Attached Files

  2. #2
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It seems like your Action class is acting like a ViewHelper. This makes the name a bit deceptive, since I would expect Action to implement a Command-pattern ?
    I do like the way you use DataSource as a transfer-layer to the View - I have been tinkering with something very similar myself. You could likely integrate your ViewHelpers (Actions) better with the View, witch could be an improvement to the overall design.
    Also - how do you handle forms? I see nothing of the kind in your setup.
    Having a ActionFactory class seems a bit like overkill to me - why not simply put the factory-method in the class itself ? I guess that's a matter of personal taste, though.

  3. #3
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    It seems like your Action class is acting like a ViewHelper. This makes the name a bit deceptive, since I would expect Action to implement a Command-pattern ?
    Yeah, I know the action chain is a little weird. I guess I'm trying to find a good way to re-use "actions" to retrieve data.

    Quote Originally Posted by kyberfabrikken
    I do like the way you use DataSource as a transfer-layer to the View - I have been tinkering with something very similar myself. You could likely integrate your ViewHelpers (Actions) better with the View, witch could be an improvement to the overall design.
    Have any ideas on how I could do that?


    Quote Originally Posted by kyberfabrikken
    Also - how do you handle forms? I see nothing of the kind in your setup.
    This is coming. I'm probably going to start with a form "listener" and a simple validator that gets integrated into the "page controllers" along with some "template pattern" methods in the controller. Do you have any thoughts on this?

    Quote Originally Posted by kyberfabrikken
    Having a ActionFactory class seems a bit like overkill to me - why not simply put the factory-method in the class itself ? I guess that's a matter of personal taste, though.
    I agree. I think that's a good idea. Thanks for your comments! I'd love to hear more...

    -matt

  4. #4
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One thing that is possible is another directory in the views directory called forms. It could be called anything. And then to get it you'd do: $formView =& ViewFactory::make('forms/signup'); echo $formView->toString(); And that would also instantiate and call the associated controller.

    Do you think a seperate FormController would be good instead of implementing "template pattern" methods into the standard controller?

    -matt

  5. #5
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    You could likely integrate your ViewHelpers (Actions) better with the View, witch could be an improvement to the overall design.
    Quote Originally Posted by mwmitchell
    Have any ideas on how I could do that?
    One way to do it would be to reverse the control. Instead of having a ViewController, witch pulls data, and push then to the View, you could let the View request data as needed. You could then do away with the (Action)chain and the ViewController.

    Have a look at :
    http://java.sun.com/blueprints/corej...iewHelper.html
    and
    http://patternshare.org/default.aspx...F.TemplateView

  6. #6
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The problem with forms is that they deal with all parts of MVC. When you are layering your application as you are, the "correct" thing to do, would be to seperate each form into three components. However - this isn't practical.

    One way to get around this is by introducing some sort of cross-cutting form-component, that handles all three layers. (think PEAR::HTML_QuickForm). This will work nicely for a start, but you are violating the basic three-tier rules of you framework, so you are heading for trouble.

    A better solution (IMHO) is to have a component witch is centered around the data and validation hereof - let's call it FormData. You could then have a Widget (a reusable View), witch accepts a FormData as a parameter. For everyday use, you could use a general FormWidget, witch renders any FormData, but you maintain the freedom to write an explicit renderer.

    For the controller-part, I would have a seperate script to handle each form. I would make it an object, and simply inherit from an abstract FormController, that handles all the trivial stuff.

    There has been several thread on the subject recently.

  7. #7
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    a reusable View
    This is a View Helper in my view. It's the job of the Helper to generate the HTML, in this case, it's a form. You may also place some validation into the Helper by association to validate any data, and choose a template accordingly.

    FormWidget, witch renders any FormData, but you maintain the freedom to write an explicit renderer.
    Wouldn't this be a Factory, returning the results of a given ViewHelper once that has been executed no? ...

  8. #8
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    One way to do it would be to reverse the control. Instead of having a ViewController, witch pulls data, and push then to the View, you could let the View request data as needed. You could then do away with the (Action)chain and the ViewController.
    OK so you are saying that instead of having a somewhat redundant step in the middle (the "view controller" class that I have), just have the views/templates call the actions right? So:

    Code:
    <table><tr><td>
    <?php $action =& Action::factory('users/list'); ?>
    <?php while($action->next()) { ?>
        <?php echo $action->get('firstname'); ?><br/>
    <?php } ?>
    </td></tr></table>
    So the actions could return a single datasource or an iterator/datasource-set. Is this what you mean? I like this a lot, but it seems to easy? Is there something I'm missing? Like I've broken a layer, but at the same time, if the actions always return a known datatype (datasource/iterator) then it seems ok.

    [/QUOTE]
    Thanks, I'll check it out today!

    -matt

  9. #9
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mwmitchell
    OK so you are saying that instead of having a somewhat redundant step in the middle (the "view controller" class that I have), just have the views/templates call the actions right?
    Yes - it's called DispatcherView if you need a patternname to justify the design ;)

    If you are mainly generating static markup with a few placeholders (as is often the case on the frontend of a website), this method works fine. Problems arise when you are dealing more complex views however.
    Quote Originally Posted by Dr Livingston
    Quote Originally Posted by kyberfabrikken
    a reusable View
    This is a View Helper in my view. It's the job of the Helper to generate the HTML (...)
    I believe that the ViewHelper could be interpreteted as either generating markup or returning intermediary data ?
    A value bean is another name for a helper that is responsible for holding intermediate model state for use by a view. A typical case (...) has the business service returning a value bean in response to a request. In this case, ValueBean fulfills the role of a Transfer Object
    (Above quote is from J2EE::DispatcherView)

    To seperate the two roles, we could refer to a reusable view as Widget and a data-fetching helper as a J2EE::BusinessDelegate ?

  10. #10
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I believe that the ViewHelper could be interpreteted as either generating markup or returning intermediary data ?
    Yes, that's how I see it as well but thus far I've only used it to return presentational HTML. You can also use this pattern in a manner to alter or prepare model data for the View in question, such as for example, reformatting a given date from

    Code:
    Sun, 12th Jan 2005
    To

    Code:
    Sunday, 12th January 2005
    A simple example I know, but I think the point is made? As for a DispatcherView, not used it, so going to follow the links you've posted now

    EDIT

    Following on from reading these links, and still reading, this part here sounds reasonable

    [DispatcherView]
    The responsibility of the dispatcher component here is to translate the logical name login into the resource name of an appropriate view, such as login.jsp, and dispatch to that view. To accomplish this translation, the dispatcher may access resources such as an XML configuration file that specifies the appropriate view to display.
    But, this part here suggests to me that the business delegate could be seen as a Controller? [MVC] As one task of the Controller [MVC] is, it not to select a View?

    [ServiceToWorker]
    On the other hand, in the Service to Worker pattern, the dispatcher might be more sophisticated. The dispatcher may invoke a business service to determine the appropriate view to display.

    The shared structure of Service to Worker and Dispatcher View consists of a controller working with a dispatcher, views, and helpers.
    The ServiceToWorker talks about a Controller, from the UML it appears to be the Front Controller, so have I missed something?
    Last edited by Dr Livingston; Apr 4, 2005 at 07:03.

  11. #11
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As for a DispatcherView, not used it, so going to follow the links you've posted now
    Sure you have - DispathcerView is synonymous with ServerPages/TemplateView in Fowler-lingo.

    I found the following quote from J2EE::DispatcherView, regarding ViewHelpers
    Helper
    A helper is responsible for helping a view or controller complete its processing. Thus, helpers have numerous responsibilities, including gathering data required by the view and storing this intermediate model, in which case the helper is sometimes referred to as a value bean. Additionally, helpers may adapt this data model for use by the view. Helpers can service requests for data from the view by simply providing access to the raw data or by formatting the data as Web content.
    So the ViewHelper could be either fetching data, or rendering data.
    To avoid confusion, I think it's rather important to distinguish between the two types. We could call the data-rendering kind for a Widget (as I suggested already). Using the name ValueBean for the data-fetching kind doesn't appeal to me, since it sounds just a tad too java-ish. Any other suggestions?

    The Widget could be implemented as a custom tag in some templating engine (as WACT does it), or by a function/class.

    The following diagram from PoEAA is taken from description of TemplateView. As you can see, the example does include a call to a helper. As far as I can tel from the diagram, this is an example of a data-returning helper (in contrast to a rendering-helper).


    The attached sequence-diagram, shows how the View would talk with the ViewHelper. You may use WACT::DataSource for TransferObject, or it could simply be a BusinessObject (If you use a DomainModel) or an ActiveRecord (If you prefer a TableModule, as seems to be the current trend among php-developers).
    Attached Images Attached Images

  12. #12
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Following on from reading these links, and still reading, this part here sounds reasonable
    (...)
    But, this part here suggests to me that the business delegate could be seen as a Controller? [MVC] As one task of the Controller [MVC] is, it not to select a View?
    The DispatcherView could go with a FrontController to select it. After selection, the FrontController will dispatch control to the View (hence the name). This dispatching could in php-terms be understood as using include().

    I think I maybe misunderstood J2EE::BusinessDelegate ... but as you can see from my previous post, I can't figure out what the word for the data-fetching-viewhelper is ? (That's what I meant when I dropped BusinessDelegate on you)

    Quote Originally Posted by Dr Livingston
    The ServiceToWorker talks about a Controller, from the UML it appears to be the Front Controller, so have I missed something?
    J2EE::ServiceToWorker has me a bit confused aswell.

  13. #13
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    To avoid confusion, I think it's rather important to distinguish between the two types.
    I think now, that between what we've posted, it is clear as to what exact a View Helper is and it's responsibilities are, so personally I don't see any confusion? I don't know (need feedback) but to call one role a View Helper, and it's other role a Widget may lead to more confusion?

    As to the other points, I'm going to see what else I can dredge up from the web, maybe something a bit more concrete I hope

  14. #14
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    code update

    OK, would you all mind checking it out now? I took out the actions, actionchain and actionfactory classes. I think it makes it too messy at this point. I have more ideas on the form handling. The viewcontrollers will be updated to extend a reflective array datasource - which essentially makes them template objects, with an execute method, and getters + setters. This will allow the viewcontrollers to check if the property has been set previously, avoiding useless calls to say a database (maybe you want a list of people from a db in the top left corner for most of the pages, but for one you want some static text set by a different view, etc...).

    The viewcontrollers will also have a var called $path. Which is always a unique value (pointing to it's location in the controller dir). This will be used to identify forms:

    <input type="hidden" name="form" value="<?php echo $this->path; ?>"/>

    Please let me know what you think! With a template engine that supports the basic php stuff I'm doing in the html pages, I think it'd make a nice little site framework.

    -matt

  15. #15
    SitePoint Guru
    Join Date
    May 2003
    Location
    virginia
    Posts
    988
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The code...
    Attached Files Attached Files

  16. #16
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I can't figure out what the word for the data-fetching-viewhelper is ?
    Fowler calls this: PresentationModel. It's something I like a lot since it clearly separates the data gathered for a view from the formatting. It also leaves very little to test via the UI (what Fowler calls "subcutaneous testing").

  17. #17
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks McGruff for the excellent link. I grabbed a quote from the article that summed up Presentation Model for me.

    "The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window, but without any of the controls used to render that UI on the screen." -- Martin Fowler

    I think this is a very useful pattern for controller based web apps.
    Christopher

  18. #18
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    There is a slight distinction between Presentation Model and a View Helper though. Might be obvious, but thought I'd just mention it anyways

    From what I can make out, this basically appears to be a very much a Business Delegate, as what this pattern actually does is to decouple the data and any behaviour from the View (presentation) in it's self via View Helpers (if any) and/or Fascade(s), as I understand it of course

    But I've not looked at your link yet so please don't quote me

  19. #19
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Fowler mentions that the biggest advantage of seperating View from PresentationModel is that it makes testing the View easier, since all the complex logic is kept in the PresentationModel.
    I came to think about a further/related benifit. Consider the example where your View contains a <select> element. This element would have to be populated from the database. If you seperate the datasource for this dropdownbox into a distinct command-object (PresentationModel), you could very easily replace your static <select> element with some AJAX component. All there is needed is that your framework must provide an xml-service, witch gives access to the PresentationModel(s).


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
  •