[TYPO3-50-general] Technical concepts for TYPO3 v5 backend

Mon Feb 9 11:36:05 CET 2009

>
> On Feb 8, 2009, at 7:48 PM, Thomas Allmer wrote:
>
> > Martin Kutschker wrote:
> >> Anway, there is all kind of stuff you can do nowadays with JS to
> >> get a
> >> decent and powerful UI. I can imagine that you can many fields in a
> >> retro way with many boring server-client round-trips, but I guess
> >> that
> >> there are limits. How shall an RTE field work without JS? Do you
> >> suggest
> >> to use only RTEs with a limited feature set that BBcode and friends
> >> offer.
> >
> > no, that's not what I said...
> >
> > it just means that there must be an textarea and if js is enabled it
> > should be replaced by a real RTE. However we start at the textarea :)
>
> I was reading a bit about progressive enhancement, the concept is 'ok'
> if you read it,
> bit for me it looks like a maintenance nightmare at the same time (for
> BE of T3 V5) plus..... read on...
>
> It's like the Boing 747 (as TYPO3 is sometimes compared to) to needs
> to beable to
> fly on coal, gasoline, neutral gas (euro 95 and euro 98) and preferred
> with or without wings.
>
> Going back to the RTE example, if you ask my clients, and I show them
> the RTE with just HTML
> code, they will NOT say to me 'Heeey cool Ries, now that's what I call
> progressive ENHANCEMENT!!'
> NO, they will simply curse me to death and ask me to get the bloody
> RTE in place ASAP.

Thats exactly what i meant in the beginning of the disussion.
Do not get me wrong - I think PE is a _must_! BUT not in every case! But
that
also doesn't mean that _everything_ has to be created in JS and there is
only a
<body></body> in our HTML content. IT HAS TO BE BALANCED! Pragmatic!

Quote from the FLOW3 Principles Website:
> "We encourage the development of well encapsulated,
> reusable code and share it in a common package repository. But we're
pragmatic, too - code which
> won't be reused doesn't need to be reusable. And if we change our mind
later, we trust on Refactoring."

I do not think that NOT strictly using PE is not reusable and maintainable -
Far from it - what i mean is that
is has to be balanced, as the quote above says.
Everything should be accessible at least for everyone (no JS links, well
structured HTML, ...) - but in case a
site of the backend uses JS and someone has JS disabled in his browser by
default (NoScript - like me)
some features / enhancements are not visible or will just not work, but no
blank page like on many other pages.
Of course there should be a nice message that she/he has to enable
JavaScript to get the full experience.

I do think that PE is good for a rendered website for various reasons,
> but a management tool that T3 V5 needs simply has some requirements
> when it comes to browser and JS compatibility.
>

Exactly. And every client has it own requirements. Different mobile devices,
braille reader, different browsers, and so on. So the challenge
is not to offer ONE backend which works for all of this clients - because
then you will get a HTML 2.0 ;-)  page which will look ugly,
is not user-friendly - which is just not usable in this times. So, if you
want then to "enhance" this HTML page, _this_ will be a JS NIGHTMARE!!
The challenge is to make it easy in development to reuse the content and to
offer different outputs for different clients and use cases, if needed.
Do not forget that, as i understood it, it is planned to have a JS
Implementation in FLOW3 (whatever JS Lib). So it will be testable,
maintainable and better refactorable.
And thats what it is important for developers:

Develop extensible high quality applications fast!

And not:

Develop good looking source code. :-D

It's like when you have content and one time you want it to be displayed as
HTML and one time you want it to offer it as XML
and one time you want it to be printable. The lowest common denominator in
this case is just the content you want to display/modify/delete.
As i said already - it has to be balanced. So no JS Nightmare, but also no
"PE is the solution for all our problems" Nightmare. ;-)