[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Typo3-dev] Services - any work??

  • From: dan at danfrost.co.uk (dan frost)
  • Date: Tue Jul 12 01:17:18 2005

>> - XML classes - we could pull PEAR etc into it.
> I'm not sure about whether or not implementing this as a service would 
> be helpful. Which advantages do you think of?

Perhaps I'm mixing up services with libraries. However, suppose you had 
a service which got an xml document (from a URL) and gave you something 

Now, because there are a few ways of dealing with xml docs in php (e.g. 
SAX, DOM etc compiled in; PEAR-libraries; PHP5's xml system) the service 
could cope with working out which one to use.

Thus, the service would be an API to PHP's (and the system's) capabilities.

>> - Datatype-independent handling. E.g. putting something into an array 
>> looks the same as putting it into a file or a database (using pull, 
>> pop, push methods etc)
> Yeah.
> I like your idea!
> It reminds me of the "Data Sources" idea that we discussed in D?sseldorf.
> However, I don't know how we could actually USE this idea in Typo3.
It's kind of where I got the idea. I also got few up putting things into 
arrays and then into files, databases etc. At the moment, the use looks 

// first we create an array to put things into
$arr1 = new ds_array('');
$arr1->pushVal('This is put into my array');
$arr1->pushVal('As is this....');
$arr1->pushVal('And this..');

// then we open file ...
$arr2 = new ds_file('myfile.txt');
$arr2->_destroy(); // this (automatic in PHP5) saves the data to file

Where $arr1 is an array API (so a bit heavier than just using an array) 
and $arr2 is a file API. But note that both ds_array and ds_file are 
children of datasource. This defines the way the objects deal with the 
"buffer" (i.e. the data in memory). The children then define how data is 
put into and got out of the buffer.

Need to settle on an API now.

>> - Really simple table-building classes
> Why should they be implemented as a service?
No idea. Libraries probably better.

>> - Email transport classes
> Jepp, would be nice to make the email functions of Typo3 use a service 
> for mail transporting. That way one can make different implementations 
> of this, one implementation using SMTP to access their provider's mail 
> server, one using the local sendmail, and the default service using the 
> PHP function mail() or something like this.
This could even be integrated into the datasources API.

>> I've also got a heap of other ideas.
> Get them out, tell us! Or at least tell the a-team [1].
I will write them up asap - by the way, I plan to make most of the 
general purpose libraries in ObTS into services.