Jump to content


Photo

check out my MVC framework


  • Please log in to reply
8 replies to this topic

#1 mrfritz379

mrfritz379
  • New Members
  • Pip
  • Newbie
  • 6 posts

Posted 21 September 2006 - 01:57 PM

Hey all, I just uploaded the source code to a framework I've been working on for a little while now. I'm not looking for a critique, so much as I'm looking for developers to help me continue to work on it (though criticism is welcome). It's a very alpha release, so I know there's lots to fix.

demo
The demo is a quick Test action that I threw up to show how the framework can handle multiple request protocols and always respond correctly. It accepts SOAP requests, XML-RPC requests, as well as standard POST/GET which will output in WAP when appropriate or when AJAX is requested, outputs raw XML. Just enter a name into the text box, select an output method and the request/response cells will show the text that is sent/returned.


If you decide you are interested in helping out or would like to download the source, the homepage is phritz.fritz-works.com. There's also a wiki up that doesn't have a whole lot of info, but lays out the basics pretty well.

From the wiki:

What is Phritz?

Phritz is a lightweight, extensible MVC (Model View Controller) framework for web application development. The main goal and purpose of Phritz is to allow developers to create display independant, standard-compliant programs in PHP.

How does it work?

Phritz works by parsing incoming requests to determine the format of the request. These requests are then wrapped in a simple Request object that is passed to a specified Controller which then passes that request to the requested method. Responses are returned in a simple Response object that is passed to the View object that corresponds to the type of request made (i.e. SOAPView,RPCView, HTMLView, etc). The View object formats the response variables appropriately and displays the finished result.

What display types does Phritz support?

Currently, Phritz supports output in xHTML, WML, SOAP, XML-RPC, and AJAX(XML). I am also planning on supporting JSON and RSS.

What's the point?

The trends toward non-standard access of web data (i.e. not through a browser) are undeniable. The use of Web Services is increasing, creating "mash-up" websites that people can use to access the content of any number of other sites. Desktop gui applications such as Flock, Firefox, Thunderbird, etc. are increasingly utilizing the web services of sites to allow users to obtain data without ever loading a web page. In addition, the use of mobile browsers is increasing, forcing companies to rewrite entire applications to output WAP format instead of standard HTML. The goal of Phritz is to facilitate the move toward these trends by allowing developers to create applications that offer these web services and WAP compatible content without having to go through the hassle of coding them manually.



#2 Daniel0

Daniel0
  • Staff Alumni
  • Advanced Member
  • 11,956 posts

Posted 21 September 2006 - 07:02 PM

Sorry, this is the wrong forum. I am not sure where it belongs, but I think it would be Application Design/Layout (No coding help).

#3 mrfritz379

mrfritz379
  • New Members
  • Pip
  • Newbie
  • 6 posts

Posted 21 September 2006 - 10:03 PM

Oh, my mistake... :-[
I thought since I was looking for feedback this would be the place. Should I re-post it, or does a mod just want to have it moved?

#4 Daniel0

Daniel0
  • Staff Alumni
  • Advanced Member
  • 11,956 posts

Posted 22 September 2006 - 05:51 AM

I guess a mod would move it. I clicked the "Report to moderator" link, so I guess that if they find it misplaced they will move it.

#5 mrfritz379

mrfritz379
  • New Members
  • Pip
  • Newbie
  • 6 posts

Posted 22 September 2006 - 01:28 PM

I guess a mod would move it. I clicked the "Report to moderator" link, so I guess that if they find it misplaced they will move it.

Great. Now they're going to think I'm posting porn or causing some trouble of some kind.  ;)

#6 akitchin

akitchin
  • Staff Alumni
  • Advanced Member
  • 2,516 posts
  • LocationCalgary, AB, Canada

Posted 22 September 2006 - 02:30 PM

nah, we read the reported topics before doing anything about them.  i'll move this.

#7 Daniel0

Daniel0
  • Staff Alumni
  • Advanced Member
  • 11,956 posts

Posted 22 September 2006 - 02:35 PM

And when reporting topics you can add a message telling what is wrong with the topic.

#8 Jenk

Jenk
  • Members
  • PipPipPip
  • Advanced Member
  • 778 posts

Posted 27 September 2006 - 05:34 PM

Hi, first off - nice work getting your own framework together, I know from experience with quite a few developers it's not always an enjoyable task :)

Also, please take this as constructive criticism - not a slating.

Your classes: for example your HTMLView class does too much. There is too much error handling, and it also has a lot of assumptions - some of which I might add are not good ones to make. A class is to do a specific job, anything that is not directly related to the object should be handled elsewhere - as such, the HTML View class should deal with presenting HTML, and nothing but presenting HTML. From the code I can see it deals with error handling, logging (not good to assume the developer will want every error logged.) This should be separated - you already have an error/exception class, so use it :)

Also, I don't mean to burst your bubble.. but strictly speaking it's not an MVC framework, too much of the Domain Logic (model) is in the view, too much of the view is in the controller etc. etc. :)

Also as more of a generic coding point, your catch blocks look like this:

<?php

catch (Exception $e) {
    switch (get_class($e)) {
    //etc..

?>

They should read:

<?php

catch (SubClassException $e) {
    // do something for a SubClassException;
} catch (OtherSubClassException $e) {
    // do something for an OtherSubClassException;
} catch (Exception $e) {
   // do something for an unexpected exception;
}

?>

You've also tight coupled a lot of your data and directory structures etc. Tight Coupling is bad, especially in frameworks :)

I also dislike the use of as many constants as you have done, but that is personal preference (but is also a form of tight coupling and also exposes such couplings to the discretion of the code outside of the class which is not always favorable.) I prefer to use a settings object.

Hope this helps :)

#9 mrfritz379

mrfritz379
  • New Members
  • Pip
  • Newbie
  • 6 posts

Posted 28 September 2006 - 04:24 PM

Hey, thanks for the feedback! I know there's still a lot of work to be done on the project, particularly in the delegation of duties among the various classes. This was mostly just a prototype announcement to show what the ultimate goal of the framework is, that is to allow clients to send requests in any number of formats and always receive an appropriately formatted response.
There are a couple of posts on my forum that mention quite a few TODOs regarding much of what you stated.  ;)

Regarding the mvc structure, I'm not sure where the errors are that you mentioned. While there is currently no real Model class implemented (you can read the post on my forum about what I'm thinking regarding that issue) I thought that the seperation of duties was pretty clear regarding the controller/view classes. The page controller methods read the request information sent and pull the appropriate data (the test module controller just appends the provided firstname parameter to a string-- no need to pull data from anywhere) and returns the response object which is then passed to the view and assigned as template parameters. Perhaps you have some suggestions that I can use to make the lines more clearly defined? :)

Regarding the exception handling in the Views, I really only did that to save on some typing since all of the error handling for the various exceptions was exactly the same except for the error message that was to be printed. But you are right as far as the amount of error handling that takes place within the view. Currently it catches all the exceptions that are thrown from the template processing. I need to set up a general Exception handler within the error class (right now it is only set up to handle trigger_error()) so that uncaught or fatal exceptions can be passed to it and then output the appropriate display. Just one of the many many many many things I haven't gotten around to yet.

I appreciate you taking the time to take such an in-depth look. If you are interested in following development, there is currently a CVS on the homepage. Its a Xoops CVS module that I'm not particularly fond of, however Sourceforge has just informed me that my project was approved today, so the Source and version info are going to be available there pretty soon. If you are interested in taking part in the development, please feel free to sign up in the forums on the homepage :).




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users