[TYPO3-50-general] FLOW3 feedback
robert at typo3.org
Thu Jun 26 12:26:34 CEST 2008
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
> theseparation. 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
So this code:
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
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 is
that we need some kind of mechanism like the above.
I could also imagine that we invent something like an HTML content
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.
> 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
will be used
- The default route can be configured through the routing
then overrides any automatic resolving strategies
Would that solve it for you?
> 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. But
of course you should be able to run the tests through command line.
Currently you can use the controller we created for running the tests
on the CI server, just type in something like
php index_dev.php Testing CLI run package-key=FLOW3 output-directory=/
and you'll find the test log as "logfile.xml" in the specified
To be honest, the whole testrunner implementation is currently a big
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
things from the CL, such as creating packages, running tests etc.
> 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!
> Keep up the good work! I am looking forward to getting a little
> moreinto FLOW3 in the coming months!
Great to hear that!
More information about the TYPO3-project-5_0-general