The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

While I can't really conjure up rational arguments, I'm still not keen on changing the signature of IHandler->execute(). Regarding you latest post, I think the LogManager may be overkill. Why would we need multiple logs ?

Me neither, which is why I thought Request/Response contexts would make sense. LogManager is there because I thought having a situation where you'll need to pass messages of two distinct types isn't too far fetched.

If we are going to pass all sort of stuff (such as $_FILES, $_SERVER and LogManager) around, I'd prefer a single ServiceLocator (Context) rather than split it into two. For example, the Loggers are output to some scripts, but input to others, which makes them odd to put in the right spot.

After a few days, I'm agreeing with you. As for my own version, I'm converting to a single Context after all.

Maybe we could give it a rest and bring it back up in a while?

I'd be much more interested in peeking into a form-factory class as the one tharos was calling for. For a start, I suppose that we could just extend the FormController class ?

Certainly. We should be moving on already. Did this episode drain all our participants?

We should be moving on already. Did this episode drain all our participants?

Well. To speak for myself, I have had the feeling for the last posts, that the discussion was more and more turning into a monologue. (Although a polyphonic one).

Arborint, who have been a driving force in the thread, obviously disapproves on the current design of the ApplicationController, which on the other hand, Ezku and I have been quite happy about. Since Ezku and I have been pretty firm on our positions, I think that arborint simply withdrew.

That said, I think that this thread is more and more evolving into a regular framework, than the pick-and-choose library it started out as. That is probably natural and may be good in itself, but I think it makes a difference.

I might want to explore that direction further, if some of you are interested in joining forces ?

Arborint, who have been a driving force in the thread, obviously disapproves on the current design of the ApplicationController, which on the other hand, Ezku and I have been quite happy about. Since Ezku and I have been pretty firm on our positions, I think that arborint simply withdrew.

Really? I was in the belief that he only disagreed on the InputProcessor part, which really is more a matter of implementation. I think the point in that whole escapade was to provide something rudimentary but extendable in order to have something for the ApplicationController to work on, not as to dictate what kind of validation process the AC should work with.

If arborint's still around, I do have interest in his state machine approach and would be extremely delighted seeing it evolve.

What is the point of having one class extend this DataSpace, and then having to create 2 instances of this same class for variable purposes? What is the responsiblity of DataSpace?

I'm lost as to what your trying to do. Also, for $_FILES, I don't see how this has actually got anything to do with a Request object of any kind either. If you require access to $_FILES then do so under it's own responsibility as well.

When I think about it some more, the whole class hierarchy has just lost me, I have absolutely no idea what the purpose of Request, Response, HttpRequest, HttpResponse are? Their responsiblities are all inter mixed and it's misleading

I still think you need to work on it some more

If you do intend to use a Context object of some sort, it should encapsulate both a Request and a Response object (the approach I use, but I don't refer to as a Context), as their dual responsibilities are clearly apparent no?

Failing that, then there is no point in continueing with it. Anyways, what is the current situation with this discussion, and is there any new script to be viewed, not including the examples already posted...

Arborint, who have been a driving force in the thread, obviously disapproves on the current design of the ApplicationController, which on the other hand, Ezku and I have been quite happy about. Since Ezku and I have been pretty firm on our positions, I think that arborint simply withdrew.

Originally Posted by Ezku

If arborint's still around, I do have interest in his state machine approach and would be extremely delighted seeing it evolve.

I'm still around and have been experimenting along my own track trying to get some time to put together some better examples.

I think where we went different directions is on how the information from the request gets to the controllers. At some point it may be a question of style, but I am not that interested in the contortions that adding a Context class requires. You might as well use a general Locator which would simplify things. But that makes it then difficult to mix and match these classes with other classes that do not use the Locator (as does the Context in my opinion). If you can get it to work in a clean way I think it would be very interesting.

I'm heading in the direction that assumes that once I get to the Application Controller I need more than the Request can provide so I abandon it. From that point on have the controllers maintain a list of objects that can contain all the associated data that goes with each field.

At this point I think I need to start working backwards from a real application to see what the Applicaiton Controller needs to provide from the application interface point of view.

There are a few classes that would be helpful for writing example apps for these "skeleton" classes, so if anyone has very, very, very basic versions (under 5Kb of code each) of the following classes please post them for use in example apps. Think of it as a coding challenge to see who can code the simplest, cleanest, smallest utility classes to the "skeleton". Needed are:

Form Field Generator class (you know: multi select, radio, checkbox, plus text, textarea, hidden). I don't care that much about form, submit, reset, etc. because those can just be in the template. It's really select, radio, checkbox that are necessary because the need to generate the selected/checked settings based on existing data. But I guess it is good to have the full set for compelteness.

If we could get those three classes we could probably code up some real world examples.

I would like to build some real application examples to show how the different ideas and code in the thread (and the Front Controller one) can be applied. That's why I asked for a couple of utility contributions to the codebase above. I would like to build some demonstration code to show controller based example app containing a plain page, a simple form and a multi-forms/pages sequence.

For Template: A str_replace() one that just used HTML templates might be simpler. If we want to go the route of PHP templates then using extract() and output buffering to capture into a string to hand off to another template or the Response. Though you could probably have both renderStr() and renderEval() as they are such small functions.

The Session one should allow direct read/write access to the session. I'm not sure the one you posted does because it imports the session data.

For Template: A str_replace() one that just used HTML templates might be simpler. If we want to go the route of PHP templates then using extract() and output buffering to capture into a string to hand off to another template or the Response. Though you could probably have both renderStr() and renderEval() as they are such small functions.

The Session one should allow direct read/write access to the session. I'm not sure the one you posted does because it imports the session data.

I hate to say this, but I'm at a complete loss here. What's an "str_replace() Template"? There's gotta be display logic in the templates and that's most simply done using native PHP. What's wrong with "caching" the Session data in the object and only writing it back on destruction? Not to say my implementation is correct (doesn't even run), but the concept should be fine.

Edit:

Nope. http://fi2.php.net/manual/en/ref.session.php: Session data is not available to an object's __destruct method as sessions are closed before the object is 'destroyed'. So how do you do this elegantly? Main-level $context->session->persist()?

I hate to say this, but I'm at a complete loss here. What's an "str_replace() Template"? There's gotta be display logic in the templates and that's most simply done using native PHP.

I don't think we want a Template class to output. We just want it to render the values into the template and return the result. Then we can either feed it to another template or pass it to the Response which will render it (if no redirect is pending).

Originally Posted by Ezku

What's wrong with "caching" the Session data in the object and only writing it back on destruction? Not to say my implementation is correct (doesn't even run), but the concept should be fine.

Nothing is necessarily wrong with it. Just more code and it requires the use of a more complex DataSpace class than the basic get/set one. I don't remember exactly how to do PHP4 Singletons, maybe just:

Seeing that my experience-lacking commentary seems to cause more trouble than it's worth, I'll try to refrain myself from messing around unless I really have something to say. I'm not exactly anyone you would want to be taught application design by.

Seeing that my experience-lacking commentary seems to cause more trouble than it's worth, I'll try to refrain myself from messing around unless I really have something to say. I'm not exactly anyone you would want to be taught application design by.

Just wondering if there is a final code archive of the "skeleton" framework?

We have been experimenting in two directions. There was code posted back in this thread by kyberfabrikken/ezku and by me. Both have functioning examples. I am trying to get some more real-world example pages together but need a few more utility classes to get there. kyberfabrikken or ezku can probably tell you better where they are at.

I didn't do a string_replace based template simply because then a templating language would need to be defined. That is okay if all we are doing is variable substition, but I don't want to be making control structures (like loops) or compiling, etc, etc. I think it would be better to simply show php-templates for basic examples, that way the class stays simple, and no-one has to learn (I know, it only takes 2 seconds ) a templating language.

As other people have mentioned, I think it's perfectly appropriate to persue several directions at once; the advantages of one approach over another may only become apparent once concrete implementations are in place, and in the end different approaches may be good for different problems.

We do, however, have to agree on this request/context thing. I personally vote for keeping the existing request and response objects and placing sessions and logging in them where appropriate. It's a tried and true approach... in any case, once we have these objects named and implemented, I think the rest will be a fair bit easier.

I don't really see the need for a template. Templates are one way to solve View-Controller seperation. Another strategy is to use a DispatcherView coupled with ViewHelpers. This is what I prefer.

Yes, I know that it is not a necessary part of this, but it is a very common implementation that I think will make examples clearer. Dispatcher View still uses a Template. It just adds a View Helper as an Adapter to the Model.

The difference between the two implementations mainly beeing that #1 is a Singleton, since it refers directly to the global var $_SESSION, while #2 allows for seperate objects within the same session.

The one you posted does not provide access to the entire $_SESSION, but only to $_SESSION[$name]. I think it will need to be separate from DataSpace because (as I recall) $this->_data =& $_SESSION; does not work.

Originally Posted by kyberfabrikken

We'd likely post to the CVS at sourceforge at some point. Right now however, we have different ideas of how to do stuff though.

There is no reason we could not post both as well. I think some of the supporting classes might have diverged a little too far at this point.

As I said, I am trying to build some examples that are more like a real app so I can see if the direction I am headed actually makes sense. That's why I asked for the Session, Template and Form Field classes. With those you can build an actual little multi-form example.

Just a basic form generator, nothing shocking. The idea behind is that your register formElements instances into the formStorageModel wich will keep track of all the elements for the form. The form decorator will used to render all the controls, as you each formelement has it's own renderer. I am not really convinced it's good, but... should work for now.

Yep. The point exactly. The one I posted will allow you to create multiple named dataspaces throughout the application, which will persist between sessions.

I haven't followed where you have taken the DataSpace class. I was just looking around the web for ideas and combined some things I found into the somewhat kooky code below.

This DataSpace allows for paths into the dataspace array. The problem with this code is that uses eval() so there might be some security issues, but I think because the paths all come from the programmer it is ok.

I took the code from the Session class above but changed it so it doesn't start the session until a value is actually accessed. This is so you can still create a session object early and not have sent headers already which I have found to be a problem with things like upload pages.