[TYPO3-50-general] Questions about FLOW3

Timo A. Hummel privat at timohummel.com
Tue Mar 17 11:54:25 CET 2009


Dear Robert,

first of all: Thank you for your time in reading and understanding my goals.

> It's not this, is it? http://www.jerrymouse.com/
> SQNR
No, luckily/unfortunately not. Unfortunately because it is hard to find
a project name plus the matching domain name. Luckily because I might
drop the project and participate in FLOW3 development/testing, since the
goals are very similar to mine.
>> used front end; that means, the base application should not be need to
>> rewritten if the user decides to switch from a web front end to an
>> AJAX/AJAJ front end. This is very important for new technologies like
>> Adobe AIR [1].
> - Enable developers to write applications which run independent of the
>
> The base application (ie. the business logic, including Domain Model,
> Services etc.) is completely independent from the controller / view.
> All data (ie. domain objects residing in the content repository) will
> be accessible through REST services and it's very easy to write your
> own REST controllers (or old-school SOAP / XML-RPC services).
>
> However, from my experience, different frontends require different
> application
> flows and therefore need their own controller / view anyway.
What I basically want to avoid is to re-create or re-implement a view
for each and every object. Of course, this is not always possible, but
some generic editors are a good start. For example, in netwatch24.com I
have the device editor, which allows editing of network devices. That
editor is very specialized, since it implements drag'n'drop, multiple
selections, canvas selection and more - this is an example where a
developer would need to implement that specialized editor for each
frontend (or backend in your notation). However, basic objects like
folders or users could be edited in a simple generic editor which simply
lists all properties in a one-after-each-other-manner; if there are
additional requirements to make it prettier/more user friendly,
specialized editors (or views) can be implemented later on.

Maybe we can coordinate developers to have a "set" of editors for
different kinds? I'm not sure yet how this could work, and it would
require quite some research, but I don't think it's impossible.
> FLOW3 comes with a Signal Slot based mechanism which can be used as a
> more powerful alternative to hooks.
Yes, I know these from the QT toolkit, which have been proven to be
pretty powerful. That's an excellent step!
> The only frontend we currently develop is TYPO3 (where it is called
> backend ...).
> I imagine that the TYPO3 backend will be so versatile and powerful that
> it will be used even without the CMS part and therefore acts as a common
> UI for many FLOW3 based applications.
Is the TYPO3 backend specific to TYPO3 or is it an univeral backend
which can serve for virtually every application? If yes, is it
relatively easy to adopt it to the domain specific objects or are there
many things to do "manually"? And: Can a developer extend the stock
TYPO3 backend? I included a sample JerryMouse frontend in my first post,
which also features the "AppCode" - which is basically a code to jump
between application just by typing a short name. As it is a power user
feature and not suitable for beginners, it shouldn't be included in the
stock TYPO3 backend, but I'm sure power users really find that one useful.
> We have that in mind but it's not the top goal for our first throw.
>
> Also remember Martin Fowler's First Law of Distributed Object Design:
> Don’t distribute your objects!
That matches my plan pretty close. It depends on how you define
distributed objects; when I talk about distributed objects, I talk about
that objects are contained in a specific installation of
(JerryMouse|FLOW3) and data is exchanged by interfaces. If you take my
example from my first posting, the web shop running on server A
communicates with the company server B containing the inventory.
> Anyway, I believe that FLOW3 is decoupled and flexible enough to be split
> up onto different servers. We also have concrete plans for a first class
> staging support (from dev server to production server etc.).
That's a very important thing; its nice to see that there are already
plans for it. If my understanding of FLOW3 is correct, then each and
every object is assigned a GUID, which makes it virtually unique (well,
not really, but close) so its easier to synchronize objects across systems.
>> - Enable rapid application development for customer-specific projects.
>> This means that a developer should be able to create a new kind of
>> application in a very simple, efficient way and is aided by tools to
>> make development easier. While this is not a requirement for the initial
>> version, it is much more important once the framework is spread.
>
> This is the very first reason why we started developing FLOW3.
>
> Look at this (Fluid-based) HTML form:
>
>  *snip*
>
> On submitting the form you end up in this action method:
>
> *snip*
>
> That's all you need to create a new blog. The arguments of your action
> method
> and their type are detected and the incoming POST data is validated and
> transformed into an object. The security framework makes sure that you're
> allowed to create new blogs.
>
> You only have to take care of the business logic and application flow.
Well, yes, its very strong tied to the end user's (=frontend user's)
experience. But I concentrate more on a business user's point of view,
who needs to manage (business) objects. Of course, with the HTML
templating approach, its easy to implement a domain-specific look on the
front end, but I'm always concerned on the backend - which makes up a
very big part of an application. I'd say that having a management
interface for a web shop needs much more work, even tough less users
will see it in the end. I know that RAD in terms of a frontend is
possible, but what about the backend? I think a simple, generic "view"
is a good start. Of course, a great solution would be some kind of user
interface abstraction language, but I think the knowledge about how to
implement such a system is not available yet - maybe someone wants to do
some research for that?
> I hope that I could give you some more insights.
Yes, thank you alot again for your time! I will still need to dig into
the depths of FLOW3, since its already pretty complex if you are new to
the conepts, but it feels "right". I got stuck at the point where it's
recommended to call typo3cr/setup/ (I get "" is no valid workspace
name), but I think I'll find out myself what the problem is. However, if
you have some pointers to follow, I'd appreciate them :)

Thanks alot!
Timo


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