[Typo3-dev] Less features, more future

[Kasper Skårhøj]

Thanks Ernesto,

I found it very interesting to read your suggestions. I think your basic ideas 
are contained in the direction v5.0 will be heading. I will save your mail 
for later reference.

Specifically I like your idea of assigning record types to pages so it is 
unambiguous where to create news items. Good idea.

Decomposing tslib_content is inevitable also. Definitely, all cObjects will be 
contained in extensions in the future.

Still, the freedom to re-think things comes at the expense of compatibility 
breaks and therefore our main constaint is when to make these changes (and 
break stuff). The direction is agreed upon generally.

- kasper



On Wednesday 12 October 2005 15:11, Ernesto Baschny [cron IT] wrote:
> 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
> _______________________________________________
> Typo3-dev mailing list
> Typo3-dev at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev

-- 
- kasper

-----------------
Think future, not feature