[TYPO3-50-general] FLOW3 feedback

Christoph Koehler christoph.koehler at gmail.com
Thu Jun 26 18:31:40 CEST 2008

Hey Robert,

Answers below.

In article
<mailman.10220.1214476007.4573.typo3-project-5_0-general at lists.netfield
ers.de> Robert Lemke <robert at typo3.org> wrote:
>  This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>  --Apple-Mail-2--54406401
>  Content-Type: text/plain; charset=US-ASCII; format=flowed;
> delsp=yesContent-Transfer-Encoding: 7bit

>  Hi Christoph,

>  Am 25.06.2008 um 07:24 schrieb Christoph Koehler:
>>   It would be much more intuitive to implement views as HTML or
>> potentially other formats. It doesn't make much of a difference for
>> me to write return "Hello World!" in the controller instead of
>> return "Hello World!" in the render method of the view class,
>> besides the separation. Returning HTML inside PHP is a big pain.

>  Returning a string by the action method is only one (the most basic)
> way to output HTML and it won't be the recommended one. What it does
> is basically set (or override) the whole content which is stored in
> the response object.

>  So this code:

>      $this->response->setContent('Hello World!');

>  is identical to just returning 'Hello World!' in you action method.

>  Anyway, as you can imagine this is not the be-all and end-all
> solution. What I have in mind is implementing sections / partials /
> whatever you call them for the response object which allows you to
> collect (HTML)code for different parts of the outputted content.

>  That means you'll be able to do something like

>      $this->response->addToPartial('JavaScript', 'alert("hello");');
>      $this->response->addToPartial('Body', '....');

>  But please note that the above will neither work yet nor are the
> method names or mechanisms carved in stone. The only thing I think is
> sure isthat we need some kind of mechanism like the above.

>  I could also imagine that we invent something like an HTML content  
>  object
>  which provides the above features and then use that as the content
> for the response object.

>  And of course that's not limited to HTML output.

Yeah I saw that you can use different template engines. I guess what I
would like to see is something like filename mapping, so that action
"show" in some controller looks for the show.html file in the view and
parses that, similar to rails. What I am afraid of is that all my
views will have the same methods in them that tell them I would like
to use template engine abc. That would mean very unDRY code with lots
of repetition.

I really like the idea of setting variables inside the controller,
i.e. a bunch of Product objects, which are automatically passed into
the view that goes with the current controller action. Then, in my
view, which is just a HTML file, I can add some logic to display those
objects, similar to Rails' <%= foreach Products as Product %> etc.

As mentioned above, as long as my code will be DRY and I don't have to
output HTML through PHP, I am happy!
>>   2. default controllers

>>   I think the default controller should be somehow determined by the
>> routing instead of the naming of the class. That way, if I decide
>> that my movie_collection controller should replace my movie
>> controller as the default, I just have to change routes instead of
>> controller filenames and class names.

>  The idea behind the naming convention was of course to avoid
> unnecessary configuration. So my suggestion is:

>     - If no default route was defined explicitly, the controller
> named  "Default"
>       will be used

>     - The default route can be configured through the routing
> configuration which
>       then overrides any automatic resolving strategies

>  Would that solve it for you?

Yep it would. Powerful routing is the key here. Ideally I should be
able to change all URLs and REST interfaces by changing just the
routes and leaving the models, controllers, and views untouched.
>>   3. more command line, please :)

>>   This may or may not be an issue, but as it is with PHPUnit now in
>> v4 and was demonstrated in the podcast by going to the /testing/
>> path of FLOW3 inside the browser, running unit tests in a browser
>> may bepretty, but very inconvenient. I hope that unit tests can be
>> easily run from the command line.

>  Using it that way turned out to be very convenient for us at least.
> Butof course you should be able to run the tests through command line.

>  Currently you can use the controller we created for running the
> testson the CI server, just type in something like

>  php index_dev.php Testing CLI run package-key=FLOW3
> output-directory=/ tmp/

>  and you'll find the test log as "logfile.xml" in the specified  
>  directory.

>  To be honest, the whole testrunner implementation is currently a big
>  mess.
>  Although it runs it's - well ... we'll have to clean it up.

>  In general, we have planned in a FLOW3 script which allows you to do
>  many
>  things from the CL, such as creating packages, running tests etc.

Thanks :) That's what I am looking for. I tried to run it from the
command line but never got it to work. Running the line above gets me:

GodFool:Public christoph$ php index_dev.php Testing CLI run
package-key=FLOW3 output-directory=/tmp/ PHP Fatal error:  Maximum
function nesting level of '100' reached, aborting! in
P_PointcutFilter.php on line 57

Fun stuff :)
As long as that's possible eventually though, that will be great!
>>   4. generators!

>>   More a suggestion than anything, and probably something that is
>> already planned: Generating controllers and stuff automatically
>> withsome script instead of manually creating files and folders.

>  Yes, absolutely planned!

Thought so, thanks!
>>   Keep up the good work! I am looking forward to getting a little
>> moreinto FLOW3 in the coming months!

>  Great to hear that!


I'm using an evaluation license of nemo since 380 days.
You should really try it!

More information about the TYPO3-project-5_0-general mailing list