SitePoint Sponsor

User Tag List

Page 11 of 16 FirstFirst ... 789101112131415 ... LastLast
Results 251 to 275 of 397
  1. #251
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    So the RequestMapper delegates to a Dispatcher and the Dispatcher delegates to a Command? Why this extra level of indirection, when you need to go to the Command in the first place?

    Why not have something like a CommandMapper which delegates directly to a Command? In the 'To hopefully clear up some confusion' there is a perfect example of a FrontController that dispatches to a Command object. What is wrong with that?

    I believe that we have a few too many 'levels' to our design, because people have different ideas of what the concepts mean.
    Nothing wrong with that, and most frameworks have integrated mappers so they work as you say. However I have supported kyberfabrikken's separated mapper from the beginning (even though my own FC does it Captain Proton's way) because it the only way to allow the Front Controller to support multiple mapping styles (and there are many). I know the flexiblity we built into the Front Controller can confuse, but the goal is to support a style spectrum from cadmiumgreen's original post to WACT/Mojavi/Rails styles. I have actually enjoyed the fact that this Front Controller implementation is different (and I now think better) from my own and has stretched my brain a little.
    Christopher

  2. #252
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    because it the only way to allow the Front Controller to support multiple mapping styles (and there are many)
    Yeah, so encapsulate that behaviour in subclasses of the RequestMapper? I still don't see why we need RequestMapper -> Dispatcher -> Command instead of RequestMapper/Dispatcher -> Command

  3. #253
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    So the RequestMapper delegates to a Dispatcher and the Dispatcher delegates to a Command? Why this extra level of indirection, when you need to go to the Command in the first place?

    Why not have something like a CommandMapper which delegates directly to a Command? In the 'To hopefully clear up some confusion' there is a perfect example of a FrontController that dispatches to a Command object. What is wrong with that?

    I believe that we have a few too many 'levels' to our design, because people have different ideas of what the concepts mean.
    This sounds a bit like what my prodedural "double dispatch" solution evolved to when I got OO/MVC religion. Your FrontController dispaches to an action, and in my case, the most complex action was "ShowView" which would then dispact to a particular ViewHelper.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  4. #254
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmm, let me put the question another way.

    When I look at the 2.6 code, I don't see any dispatchers in there, only a RequestMapper (an ActionMapper and a ServerPageMapper). So you can map requests to Action objects and to php includes. Perfect! That is how I would do it. But for what problem exactly do we need a dispatcher in between?

  5. #255
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    Hmm, let me put the question another way.

    When I look at the 2.6 code, I don't see any dispatchers in there, only a RequestMapper (an ActionMapper and a ServerPageMapper). So you can map requests to Action objects and to php includes. Perfect! That is how I would do it. But for what problem exactly do we need a dispatcher in between?
    The word dispatcher has been used in two ways so far; as an alternate name for a controller, and to refer to the objectreturned by the RequestMapper and then executed. In the case of the latest code, it's the Action object or the ServerPage. It has never been another layer that sits between the Controller and the Command object.

    I think we can all agree that the term is causing confusion, and it that we need to get rid of it...

  6. #256
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I think that is a premature optimazation. Also from experience the Front Controller is just different enough that it does not really fit with the other controllers. The RequestMapper is pretty unique in it variation between frameworks. The other controllers use switch/CoR style mapping. Plus, as every request goes through the Front Controller, it should just do its job as simply and efficiently as possible. Finally "Dispatcher" is a generic term whereas "Front Controller" immediately communicates what it is and does. If all the controllers will be using this Command that accepts Request and Response parameters then I would call it ControllerCommand or ControllerHandler.
    This is what our (my) FrontController looks like:
    PHP Code:
    class FrontController implements IHandler
    {
        protected 
    $mapper NULL;
        public function 
    __construct(IRequestMapper $m)
        {
            
    $this->mapper $m;
        }
        public function 
    execute(Request $requestResponse $response)
        {
            
    $handler $this->mapper->mapRequest($request);
            if(
    $handler instanceof IHandler)
                
    $handler->execute($request$response);
        }

    I think it's pretty generic, and doing it's job as simply and efficiently as possible. A FrontController is something that should appear in an app once - in the front. But if you want a second level of dispatch, we need another dispatcher - and that's bound to look like this as well. So why not make this class the Dispatcher right away?

    I'll back off if you can convince me that there's ~never a need for two layered FrontControllers with their own RequestMappers.
    Quote Originally Posted by Captain Proton
    So the RequestMapper delegates to a Dispatcher and the Dispatcher delegates to a Command? Why this extra level of indirection, when you need to go to the Command in the first place?
    The RequestMapper can delegate to a Dispatcher just as it can delegate to a Command straight away. There's no "must". If you need a second dispatch, you've got it, but if you don't - well, you're set. I think this already demonstrates the flexibility we're going for.

  7. #257
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatjo
    This sounds a bit like what my prodedural "double dispatch" solution evolved to when I got OO/MVC religion. Your FrontController dispaches to an action, and in my case, the most complex action was "ShowView" which would then dispact to a particular ViewHelper.
    Yes and I make sure to mention your "double dispatch" solution as I think it describes well the direction a "shared nothing" solution needs to go. We are trying to be more flexible than framework's controller implementations. One of our goals here is to be able to dispatch pretty much anything: a PHP file, a View object or a Controller that controls a View object.
    Quote Originally Posted by Captain Proton
    When I look at the 2.6 code, I don't see any dispatchers in there, only a RequestMapper (an ActionMapper and a ServerPageMapper). So you can map requests to Action objects and to php includes. Perfect! That is how I would do it. But for what problem exactly do we need a dispatcher in between?
    We don't because the Front Controller itself is the Dispatcher (hence some of the confusion). It gets the "action object" from the mapper and dispatches it so the mapper controls the behavior. It is kyberfabrikken's clever solution to add a flex point here (once I understood it) that got me interested in the first place.
    Quote Originally Posted by 33degrees
    The word dispatcher has been used in two ways so far; as an alternate name for a controller, and to refer to the objectreturned by the RequestMapper and then executed. In the case of the latest code, it's the Action object or the ServerPage. It has never been another layer that sits between the Controller and the Command object.

    I think we can all agree that the term is causing confusion, and it that we need to get rid of it...
    One of the things controllers do is dispatch so I can see how a controller as simple as our Front Controller could be called a Dispatcher. The object returned by the request mapper is not a dispatcher, it is dispatched. Maybe that has something to do with the confusion.
    Quote Originally Posted by Ezku
    I think it's pretty generic, and doing it's job as simply and efficiently as possible. A FrontController is something that should appear in an app once - in the front. But if you want a second level of dispatch, we need another dispatcher - and that's bound to look like this as well. So why not make this class the Dispatcher right away?

    I'll back off if you can convince me that there's ~never a need for two layered FrontControllers with their own RequestMappers.
    I don't think you are going to find another Controller with a constructor that takes a Mapper and dispatches Commands that take request and response as parameters. That is a Front Controller. The fact that it is so simple is deceiving, but it is also highly specialzed.
    Christopher

  8. #258
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    One of the things controllers do is dispatch so I can see how a controller as simple as our Front Controller could be called a Dispatcher. The object returned by the request mapper is not a dispatcher, it is dispatched. Maybe that has something to do with the confusion.
    I'd say the confusion comes from the code. Look at the controller, the object returned by the mapper is stored in a variable called 'dispatcher', which implies something that dispatches, and therefore sits between the front controller and the action object that gets executed. This needs to be changed, in my opinion.

    PHP Code:
    class FrontController
    {
        var 
    $mapper;

        function 
    FrontController(&$mapper) {
            
    $this->mapper =& $mapper;
        }

        function 
    execute(&$request, &$response) {
            
    $dispatcher =& $this->mapper->mapRequest($request);
            if (
    method_exists($dispatcher'execute')) {
                
    $dispatcher->execute($request$response);
            }
        }
    // end class FrontController 

  9. #259
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Yes and I make sure to mention your "double dispatch" solution as I think it describes well the direction a "shared nothing" solution needs to go. We are trying to be more flexible than framework's controller implementations. One of our goals here is to be able to dispatch pretty much anything: a PHP file, a View object or a Controller that controls a View object.
    So why do you want to prevent having another Dispatcher with a RequestMapper? Say I want to handle failed mapping attempts at a FailedRequestMapper. I would have my RequestMapper return one wrapped in a Dispatcher (which equals your FC) to use it. Perhaps the associated jargon is throwing everyone off, so I'll just demonstrate with a bit of code.
    PHP Code:
    class MyRequestMapper implements IRequestMapper
    {
        (...)
        public function 
    mapRequest(Request $request)
        {
            (...)
            if(
    $this->failed)
                return new 
    Dispatcher(new FailedRequestMapper);
            else
                return new 
    $action_class;
        }
    }
    class 
    Dispatcher implements IHandler
    {
        (...)
        public function 
    execute(Request $requestResponse $response)
        {
            
    /**
             * On failure, the Dispatcher that works as FrontController receives another Dispatcher
             */
            
    $handler $this->mapper->mapRequest($request);
            
    /**
             * This Dispatcher is executed, resulting in mapping the request again - this time by a
             * FailedRequestMapper that knows how to return a, say, 404 error action
             */
            
    if($handler instanceof IHandler)
                
    $handler->execute($request$response);
        }

    I don't think you are going to find another Controller with a constructor that takes a Mapper and dispatches Commands that take request and response as parameters. That is a Front Controller. The fact that it is so simple is deceiving, but it is also highly specialzed.
    In my mind we'd need to distinct a Dispatcher and Controller from eachother. For the purposes of our skeleton a Dispatcher could be a Controller that executes based on a RequestMapper, whereas a plain Controller does something entirely else - which could be dispatching to an Action/Command based on what's already in the Request.
    Quote Originally Posted by 33degrees
    I'd say the confusion comes from the code. Look at the controller, the object returned by the mapper is stored in a variable called 'dispatcher', which implies something that dispatches, and therefore sits between the front controller and the action object that gets executed. This needs to be changed, in my opinion.
    I agree. I already changed it to $handler some time ago, as per your previous suggestion.

  10. #260
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    PHP Code:
    class MyRequestMapper implements IRequestMapper
    {
        (...)
        public function 
    mapRequest(Request $request)
        {
            (...)
            if(
    $this->failed)
                return new 
    Dispatcher(new FailedRequestMapper);
            else
                return new 
    $action_class;
        }

    Alright, I think it's alright to call me a dookus now. I've been trying to push a totally useless change for a day or two only to realize it just might be simpler to do
    PHP Code:
    if($this->failed) {
       
    $mapper = new FailedRequestMapper;
       return 
    $mapper->mapRequest($request);

    Cursed be all the newbies infiltrating a totally intelligent and reasonable conversation. And that includes me. My apologies for being a total jackass. My only excuse is getting caught up on being as flexible as possible. But the skeleton should optimally discourage bad design, shouldn't it.

  11. #261
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No need to curse as we are all learning from this discussion. It is great that this thread investigates many ideas so we can see why or why not to include something. And following from the original design we decided to have the mapper deal with all mappings including errors. It is the customizable piece in this.
    Christopher

  12. #262
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Let's check to see if we all agree on certain things now, before proceeding to the next stage. I'll try to make as complete a list as needed:
    • Page flow starts with constructing the FrontController
    • The FrontController takes an object implementing IRequestMapper as its constructor argument
    • The FrontController implements IHandler
    • IHandler defines the execution method, which takes two arguments: a Request and a Response.
    • The FrontController uses the RequestMapper to fetch an object implementing IHandler
    • The Handler is executed by the FrontController
    • Page flow ends with a main level call to Response->out();

    In addition to this, there is the HandlerChain object.
    • The HandlerChain object can be used to construct a chain of Handlers; this may be used eg. to filter the Request or create Controller tree structures
    • Any IHandler-implementing object (The FrontController, "Filter" objects, Controllers or HandlerChains) may be added to the chain
    • When the HC is executed, the contained Handlers will be executed one at a time in the order they were added
    • Note that this is a straight chain and not a Chain of Responsibility

    Included is a PHP5 version of this, implementing a basic use case scenario.
    Attached Files Attached Files

  13. #263
    SitePoint Guru dbevfat's Avatar
    Join Date
    Dec 2004
    Location
    ljubljana, slovenia
    Posts
    684
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Anybody thinking of summing up this thread in an online article with downloadable code?

  14. #264
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have updated kyberfabrikken's last code to change FilterChain to HandlerChain and to call all the objects that have an execute($request, $response) method as $handler. (if we don't reuse HandlerChain we may want to rename it FrontHandlerChain). I think we can put it aside for a while and move on to the Application Controller. The code is:

    http://ap3.sourceforge.net/skeleton2.7.zip


    Application Controller

    I tracked down the Dai and Knight information that Fowler refers to in PoEAA here: Objects vs the Web PDF. It is a lot of information, but I think it might give people a primer on this subject. Please note that we need to start small and focused. I don't want people to start focusing on features until the core is agreeable to most.

    Here are some parts for an MVC implementation. I would like to note that our system should be able to support using none of these parts, or simply puting a Transaction Script behind the Input Controller, or any other configuration.

    Input Controller which filters and validates data from the Request for use by the Application Controller.

    Application Controller which selects the Model and View based on data from the Input Contoller and state information it maintains.

    View that accepts data from the Model and Application Controller to build the Response.

    Model containing domain logic cleanly separated and only depending on the Data Source layer.

    Data Sources to retrieve data from databases, files, the session, etc.

    As the Application Controller is usually a state machine then we will inevitably end up discussing state and transitions, and the events that trigger them.
    Christopher

  15. #265
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dbevfat
    Anybody thinking of summing up this thread in an online article with downloadable code?
    I think the best thing to do would be to document everything thoroughly, both in the code and on a wiki, and then release the code officially on sourceforge. We already have an account there to do so, may as well make to most of it...

  16. #266
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the best thing to do would be to document everything thoroughly, both in the code and on a wiki
    Rather than document the code I had hoped that someone would create at least one unit test for each class. Others could add from there. Any volunteers?
    and then release the code officially on sourceforge.
    Which leads to an interesting question. What license if any should this be released under. Do we want the LGPL's requirement to give back improvements.
    Christopher

  17. #267
    SitePoint Guru
    Join Date
    Jul 2004
    Location
    Netherlands
    Posts
    672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes it would be great if somebody could document the code, currently i also use a simple switch statement.. but would like to learn something which would be more extensible and allow a larger scale of scripts...

    btw would it be wrong to simply include a variabele include path?
    Go visit my site :-D you know you want to ;-)
    www.mech7.net

  18. #268
    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 arborint
    I have updated kyberfabrikken's last code to change FilterChain to HandlerChain and to call all the objects that have an execute($request, $response) method as $handler. (if we don't reuse HandlerChain we may want to rename it FrontHandlerChain). I think we can put it aside for a while and move on to the Application Controller.
    You removed /* implements IHandler */ from FrontController and HandlerChain. Was that on purpose ?

    I read the slide through page 90. Appearently Dai&Knight's use of ApplicationController matches the RoR style mapping.
    Quote Originally Posted by Dai&Knight pg. 80
    Actions become methods in (Application Controller)
    By Actions they refer to, what I have been calling Dispatcher, and which have now been renamed to Handler. It's the Command object, which the FrontController gets from the RequestMapper.
    Curiously Dai&Knight have an ActionMultiplexer and ActionRegistry, which translates directly to FrontController and RequestMapper. (Dai&Knight pg. 62)

    Anyway - the purpose of the ApplicationController as explained by Dai&Knight, is simply to group Handlers together in a common namespace. The aim seems primarily to be a reduction of classes. I can't really see the great benifit of this, but I recon that some would. Then again - I love heaps of tiny classes, and looking at the available php-code (PEAR?) that's not the mainstream of the php-community.

    This behaviour could be quite easily implemented by using a slightly more complex Handler returned from the RequestMapper. I have already shown this in post #90 and again in #191.

    Anyway - I think it may be a better call to close this thread down and document and test what we got already. We can put a RoR style Handler (~ApplicationController) in the project - It's not overly complicating anyway. It would also serve the purpose of showing that different types of mapping are possible with the codebase.

    I'll check the code provided by arborint (2.7) into cvs, and add a revised version of the actionpackmapper from posts #90 & #191. After that, I'll try to get time to write some unittests for some of the classes. If someone is eager to do that, they should feel welcome to beat me to it.

    Quote Originally Posted by arborint
    What license if any should this be released under. Do we want the LGPL's requirement to give back improvements.
    You can consider anything I post on theese boards as public domain. I honestly don't care. Unless there's any objection to it, I say we stick a "creative commons" license to it and be done with it.

    Quote Originally Posted by pixelsoul
    btw would it be wrong to simply include a variabele include path?
    What do you mean ? Like sticking a constant in front of all paths in the require_once statements ? I personally prefer to tamper with the include_path through ini_set()

    Edit:

    The code is now available in cvs.sourceforge.net:/cvsroot/ap3 module "Skeleton". I started adding some tests, but help on that arena is highly appreciated.
    Last edited by kyberfabrikken; Jun 23, 2005 at 05:02.

  19. #269
    SitePoint Guru
    Join Date
    Jul 2004
    Location
    Netherlands
    Posts
    672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
    // Switch on the page GET variable
    $file $_GET['page'];

    require_once (
    modules/$file); 
    Would this pose to much security issues?
    Go visit my site :-D you know you want to ;-)
    www.mech7.net

  20. #270
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pixelsoul
    PHP Code:
    $file $_GET['page'];
    require_once (
    modules/$file); 
    Would this pose to much security issues?
    Yes; ?page=../../../../my/malicious/script.php. But things like this really don't belong in this thread and I don't think they belong in this section either.

  21. #271
    SitePoint Guru
    Join Date
    Jul 2004
    Location
    Netherlands
    Posts
    672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I dont know basically this is what the skeleton script does correct?
    at least with example_serverpage.php.

    With the other ones it also seem to run a class with the same name.

    Quote Originally Posted by Ezku
    Yes; ?page=../../../../my/malicious/script.php. But things like this really don't belong in this thread and I don't think they belong in this section either.
    Go visit my site :-D you know you want to ;-)
    www.mech7.net

  22. #272
    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)
    Please don't take this the wrong way pixelsoul, but your question is rather hard to answer, because you don't understand the basic premises for the whole discussion. Rather than try to educate you in a lenghty post, I would suggest that you read up on the programming-concept called design patterns, and in particular the Front Controller pattern, which is what we have been dealing with for the last 270 posts.
    You could start out by reading some of the exellent articles at phppatterns and if you feel like you want more, I can recommend that you buy the book Patterns of Enterprise Application Architecture by Marting Fowler.

  23. #273
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    Yes; ?page=../../../../my/malicious/script.php. But things like this really don't belong in this thread and I don't think they belong in this section either.
    I think you are perhaps wrong there. If you provide a model solution for the FrontController problem which actually contains a gaping security hole, you are perhaps doing a greater dis-service than not having provided the code at all.

    And I agree with Christopher, unit tests would be much better than simple documentation of the code.

  24. #274
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I tracked down the Dai and Knight information that Fowler refers to in PoEAA here: Objects vs the Web PDF. It is a lot of information, but I think it might give people a primer on this subject. Please note that we need to start small and focused. I don't want people to start focusing on features until the core is agreeable to most.
    I read through most of that. It did provide some ideas, but most of them seem viable only in an environment such as Java and are not applicable to PHP as is.

    I don't think we need a separate "InputController" between there. If Actions need to validate input that's passed to the Model, they should be able to do it, but an additional layer merely for this purpose seems a bit off. Redirecting to a page to correct the input values should also be a concern for the Action. Don't take this too literally:
    PHP Code:
    class MyAction extends Controller
    {
       public function 
    execute(Request $reqResponse $res)
       {
          (...)
          try {
             
    $model->data $req->data;
             
    $MyModelValidator->validate($model);
             
    $view->addTemplate('success.htm');
          } catch (
    ValidationException $e) {
             
    $view->assign('ValidationErrors'$e->getMessage());
             
    $view->addTemplate('form.htm');
          }
       }

    The ideas proposed in the pdf seemed very platform- and framework-specific. Perhaps it's just that I didn't understand what was going on, but Context objects and such didn't seem like anything I'd want to do. Feel free to convince me otherwise, though.
    Last edited by Ezku; Jun 23, 2005 at 08:13.

  25. #275
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Rather than document the code I had hoped that someone would create at least one unit test for each class. Others could add from there. Any volunteers?
    Unit tests are an excellent idea, but in my opinion are a complement and not a replacement for proper documentation. I'm still learning about unit tests, so I couldn't be of much help there, but I would be very happy to work on a documentation effort.

    Quote Originally Posted by arborint
    Which leads to an interesting question. What license if any should this be released under. Do we want the LGPL's requirement to give back improvements.
    LGPL sounds good to me; however, I suggest we set up another venue (like a mailing list) to discuss issues like this, to keep the discussion here focussed on the actual programming.


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
  •