[Typo3-dev] Structural Ideas

Daniel Hinderink daniel at typo3.com
Thu Jun 26 17:34:32 CEST 2003


Hi,

Thanks Ingmar, I can now safely bash René, since he is on holiday, unless he
is checking his mails on the beach :-)

> Heyho
> 
>> Now my idea is to introduce a new sort of objects to TYPO3:
>> Sources.
>> Sources are
>> A.) in the site root, like filemounts.
>> They should hold Database-settings and can be attached to branches of the
> ...
>> Other source-types could be LDAP-settings, ODBC, WebService infos.
> ...
>> B.) Attached to a page: XML-streams (RSS/RDF), OODocs or even individual
>> Queries.
> ...
>> of the extension logic would be to provide a source-format that can be
>> created through the extenion system and plugs neatly into the general
>> architecture.
> 
>> From the theoretical point of view it sounds good but from my more pratical
> view I've got some questions:
> 
> - did I get it :-)

I would be thrilled if you did. Often I have no idea what I am talking about
:-)

> - what type is the 'source-format'
> - what are the benefits?
> 
> The whole thing sounds to me like the idea with XML. You have one kind of data
> source/type, you can write tools that can handle the data and don't have to
> know about it. Sounds all great. But at one point in the whole XML chain you
> just have to know about the data format of your XML stream. At this point XML
> is just one data format (a good one) besides others.
> 
> So the idea seems not to belong to a data format than to a data source (as the
> name says). But what makes it so flexible to hide the data source from the
> data processing application? For example a plugin that renders RSS can't do
> anything else, and the source of a RSS feed is an URL (in very most cases!?).

<general explanation>
Well, I am aware that my idea is nothing more than the proposal of a basic
concept (instead of something practical) and of course
XML/RSS/semantic-web-babble is to blame for this. But the other reason to
dabble with this concept is, that when looking into Zope, I feel it has a
thwarting degree of flexibility to offer concerning the ins and outs
available. That can not be compensated for because of the architecture in
general and Python in particular, but thinking of what the EM did for TYPO3
I was wondering wether there was another direction for extensibility to
think of. Stupid? Daniel-take-a-cooky-sit-down-and-shut-up?
</general explanation>

Concerning the data format, which is the problem at the heart of your
addition it seems, I understand that there is of course no general solution
architecture for this possible like this:

-source connector
-format filter
-data cache for t3 use

But something like this might be possible for a lot of situations.

Take Agent K's Totally Ludicrous Moody Lunacy (aka TSML). Picture this being
a source extension making this DTD or scheme available as an input format
for template info. The file is located in the source connector, the format
is determined by some definition in the format filter and the data cache is
(if needed) stored somewhere inside the system.

Now play the same before your mental eye putting in XSLT instead of TSML.

Hey, I didn't say we should do this over the week-end, but just wanted to
start a discussion on how to make t3 more powerful on this end of things.

> 
> I think a data processing application belongs to a data format which belongs
> very often to a specific data source.
> 
> But anyway...
> 
> To hide the data source we still need a data type description:
> - text (with meta type)
> o it's simply text
> o postscript
> o xml
> o ...
> - array (eg: record from database)
> - binary (with meta type)
> 
> Then an application (plugin) can tell what type of data it can handle and a
> fitting data source can be applied
> 
> BTW: what's about the new 'streams' in upcoming php versions?

I will look into this.

> 
> 
> 
>> Second Idea:
> 
>> the database tables and backend forms, but also a front end generator that
>> shows the available fields in a selected table, make it possible to make a
>> selection among these and then generates front end forms that can be
>> inserted in the page.
>> 
>> I know this could only be done in some graphically simple form, but this
>> would suffice in 90% anyway.
> 
> I simply agree!
> 
> A form designer would be great. What's about Christian'S feEdit API (haven't
> tried yet)?

We (dpool) started looking into it, because we need it in a current project
and we meant to get in contact with Julle regarding the advancement of it.

Anyone else in need of something like this? I am not sure, but did Carsten
Rose not start making something of this sort as well?
Carsten, are you listening?

Cheers,

Daniel


-- 
TYPO3 - get.content.right

Daniel Hinderink
Marketing, Press Relations, Strategy
http://www.typo3.com






More information about the TYPO3-dev mailing list