[Typo3-dev] Less features, more future

[Ernesto Baschny [cron IT]]

Kasper Skårhøj schrieb am 12.10.2005 12:48:

>>1. Pagetypes: Hide in Menu, Advanced, Backend User Section, Spacer, huh?
>>Why can't we just have page properties, nicely arranged and collapsable,
>>but with the possibility to have any combination of them. Quite a few
>>feature requests in the bugtracker go like "I want checkbox X in
>>pagetype Y". Since Pagetype is essentially only a filter field, this
>>should be trivial to implement even without breaking stuff (as Stucki
>>pointed out concerning not-in-menu).

> I agree. Today the page editing form should have tabs to divide the different 
> types. Maybe you can justify types like Sysfolder being different.

The "pages" table is currently used for two purposes, which is why it
might be difficult to eliminate the types:

1) as hierarchical containers for other record types
2) as menu entries for the webpage with their respective content

For a beginner its a bit confusing. You place "content records" inside a
"page", that's ok, because this is what will get outputted when the user
sees this page in the frontpage. But you can also place "news" and other
stuff (frontend users, etc), which doesn't have a direct meaning on the
page where its placed.

This is why I agree with Kasper, there is a good reason to differenciate
between a "Page" and a "SysFolder".

Which brings me to another "wish" I have expressed some months ago: The
TYPO3-site developer should be able to specify which records are allowed
to be placed on which pages in the tree. Maybe we want only "Content"
elements in our page hierarchy, and a certain SysFolder that will only
store our News, so that our newby-user doesn't start creating "news"
records all over the site, just in this particular folder.

And allow the site implementator to tag each page in the tree with a
particular icon, we can get rid of the "contains plugin" field, which I
found myself just using to give my news-folder a "News"-like icon.

>>3. Content Elements: search box, login have been superseded by
>>index_search and newloginbox (and others). Either replace them or get
>>rid of them completely.

> Hmm. I agree for modern sites they should be disabled. Yet, they do their 
> simple job.

Which could be done in an extension. So if I want this particular
"search box", I install an extention, just like everything else in
TYPO3. It could be shipped with TYPO3 and even enabled by default, but I
would like to disable it altogether (also the source-code that is
responsible for it!).

Which brings me to tslib_cObj: This is a huge class that contains a lot
of the most fundamental rendering features of TYPO3. Problem is, its
huge, its full of hardcoded HTML and its not easily extendable.

My dream would be a stripped down tslib_cObj which can be "enhanced" by
extensions. I like the "obts" approach, where I can create new cObjects
in my extentions? Why not include this feature in TYPO3 by default? And
when doing that, we can remove all rendering stuff from this class to an
external extension! The admin then installs the needed extensions, which
will provide different cTypes and the appropriate rendering engines. So
if the admin doesn't install the "content_multimedia" extention, we
won't have a MULTIMEDIA TypoScript object, and we won't have a
"Multimedia" content-type either. And if some extension wants to
implement its own MULTIMEDIA content type, just provide the TypoScript
object with the needed parameters, add the cType to tt_content and add
TypoScript to tt_content. The benefit of it is that all extensions can
use the provided "MULTIMEDIA" content type, not only tt_content!

This would also apply nicely to my current cron_cssstyledimgtext. TYPO3
renders the "textpic" cType in content(default) and css-styled-content
by using the "IMGTEXT" TypoScript object. Currently, to be able to
change this behaviour I have to:

1) change the TypoScript in tt_content.textpic and tt_content.image so
that its no longer an "IMGTEXT" but an "USER" object that will call my
function
2) do the rendering in my function.
3) problem: any direct call to IMGTEXT (e.g. from another extention)
won't get my rendering, it will be rendered by TYPO3's default engine.

With my approach, it would work like that:

1) create a new "IMGTEXT" TypoScript object.
2) the admin chooses which IMGTEXT to install as an extention
3) if mine is installed, any other place that needs an IMGTEXT will get
rendered through my engine.

Some benefits of it:

* tslib_cObj gets a lot smaller, and a site only needs to include stuff
that he really needs.
* obts included allows any extension to create its own TypoScript
object. Instead of

temp.myStuff = USER
temp.myStuff {
 userFunc = blabla->render_imgtext
 ...
}

we just need:

temp.myStuff = IMGTEXT
temp.myStuff {
 ...
}

Some might tell me to ask for hooks to get the desired features, but
then I have to depend on when a hook is implemented. If this is
extendable by default, I don't need a hook.

Some others might tell me I can already use stdWrap to post-process any
cObject in the way I want it. But I don't want to post-process anything,
I want to process it in the first place. If I would hook
cron_cssstyledimgtext onto stdWrap, TYPO3 would render it as a table,
and I would then throw that away and render it in another way. Ugly.

>>4. Fields in content elements: Space after/before, Frame, Align? All
>>those can be replaced by *one* CSS-class field in which these properties
>>can easily be defined for the wrapping div field.

> Good.

Which brings me to another thought I was having these days: Configurable
CSS through TypoScript! Currently each extension can bring its own
"_CSS_DEFAULT_STYLE" which will be added to the page (or exported to a
temp-file, if one set it in config).

I just found out (thanks ben!) that I can use constants in this
_CSS_DEFAULT_STYLE. This is a huge improvement, as I am much more
flexible then. I provide a CSS that can be configured through CONSTANT
EDITOR. NICE!

But my dream would be a more enhanced control over the CSS, that means,
I would like to have CSS being generated by TypoScript! Basically I
would love to be able to do things such as this in TypoScript for my plugin:

plugin.tx_myplugin._CSS {
  10 = CSS
  10.selector = P.csc-caption
  10.properties.font-size = 80%
  ..
  20 = CSS
  20.selector = DIV.csi-textpic DIV.csi-imagecolumn
  20.properties.float = left
  20.properties.display = inline
  ...
  30 = CSS
  30.selector = DIV.csi-intext-left-nowrap .csi-text
  30.ieWinOnly = 1
  30.properties.height: 1%
}

which would generate:

P.csc-caption { font-size: 80%; }
DIV.csi-textpic DIV.csi-imagecolumn { float: left; display: inline; }
/* Hide from IE5-mac. Only IE-win sees this. \*/
* html DIV.csi-intext-left-nowrap .csi-text { height: 1%; }
/* End hide from IE5/mac */

And of course everything goes through stdWrap, so the possibilities are
endless. I could override or add certain CSS-settings in an extension
template (e.g. the font-size for captions for a certain page-tree)
without having to manually create external CSS files. Its also
extension-upgrade-proof, as the properties will remain in place, so if
the extension upgrades its CSS-feature-set, I can be sure it will work
in my template without me having to check my external CSS files.

>>5. Typoscript properties: I'm sure there's lots more, but here are some:
>>XHTML-cleaning, disableImgBorderAttr, page.bodytag etc. - these are ugly
>>hacks. Instead, let's make it XHTML strict (or trans for the beloved
>>target-attribute which also pops up everywhere in TS) and that's it.
>>Yes, HTML 4 is not obsolete yet but why would you need to use this (and
>>please don't come up with that legacy stuff again.)? If you think: Why
>>can't we just leave it in, please see the condition hell when rendering
>>stuff, the various places where tags are changed afterwards, and ask the
>>content rendering group.

> yes, lets face the future.

True. TYPO3 should output XHTML 1.0 trans in its "core" extensions.
Generate HTML output from this is easier than the oposite.

>>xMENU_LAYERS: This may be a personal issue but the configuration is
>>horrible, the resulting html not very nice, and most of all: it can all
>>be done with a regular xMENU, some CSS and JS.

> I'm not so sure.

I never used them. But with "obts" and my ideas from before in place and
moving such features to extensions, we could have xMENU_LAYERS on all
needed flavors, the admin chooses which one to use and uninstalls the
ones he doesn't need.

>>cObjects: PHP_SCRIPT_x, CTABLE, OTABLE, HRULER?, CLEARGIF???!

> In fact PHP_SCRIPT_EXT had a surprising comeback in a discussion I had with 
> JH, but theoretically yes.

Never used it. But I would love to hear which comeback is planned for
this! :)

On CTABLE, OTABLE, HRULER, CLEARGIF, I agree with Michael: Ban them into
their own extensions, if someone wants them, install the extension. I'm
sure someone will then create a substitution CLEARGIF or HRULER
extension that is purely CSS-based! :)

> These changes will however not apply to version 4.0. Some might apply to 
> version 4.5 due to their usability enhancement effect. And all of them - and 
> possibly going much further - will be the home of version 5.0 in my mind.

I agree with that plan. I also see 4.0 as a release to "zap the
gremlins" and have a nice base that we can work on.

> Thanks for your input. Maybe others have some dreams about the future? Anyone?

Here I am... :)

> BTW: "Think future, not feature" was invented as a slogan for a little sales 
> speech to the supporting members of the association where I wanted to stress 
> the point that much of the future core development will not be focused 
> directly on creating a new gizmo this-or-that but needs to deal with 
> architecture etc. that can prepare TYPO3 for a long-term life. Hence be an 
> investment we must trust is for the better.

Wise advice, I like the way this is heading!


Cheers,
Ernesto