[TYPO3-ect] TYPO3ext: direct_mail mergers & acquisitions

[Elmar Hinz]

Hi David,

David Toshack wrote:
> 
> Yes, I imagine the partner extension will mature a lot over the coming
> weeks, hopefully to support the new official tx_lib and tx_div. And the
> partner_fe extension to follow in the footsteps of tx_articles.
> And hopefully soon, tx_forms.
> 

I think we shouldn't build dependencies between them before each of them is
beta. If we weave them to early, it becomes difficult to alter and improve
the APIs.

I regard tx_articles as the testfield, where most of the concepts can be
proved. So there will be a lot of changings in tx_articles within the next
monthes. Currently I experiment with flex fields.

I am also curious how tx_cal works as a real calendar base. If we plug
tx_articles to tx_cal togher the output should be a news system. Right?

>> David try it. Set up a pool of interested people. Maybe we can get it running.
> 
> Sounds good. Should we consider starting again with an official tx_mail
> extension to combine the best features of all the direct mail based
> extensions in the MVC model?
> 

If you choose the name tx_mail it should be a mail object rather than a
specialized bulkmailer. Object orientated in the style of tx_lib_link:

$mail = new tx_mail();
$mail->title($titleString);
$mail->from($senderString);
$mail->to($recipientStringOrArrayOrObject); // autodetection
$mail->cc($recipientStringOrArrayOrObject); // autodetection
$mail->bc($recipientStringOrArrayOrObject); // autodetection
$mail->headers($array);                      // additional headers
$mail->content($textStringOrContentObjct);   // autodetection
$mail-> ...
$mail->send();

If every function returns $mail itself you can also write:

$mail->title(love)->from(me)->to(you)->content(kiss)->send();

But I would suggest that you put such a class into tx_lib => tx_lib_mail.

I specialized bulkmailer would use tx_lib_mail, but needs an independent
extension. Maybe tx_bulk? That's where cronscript etc. is included.

> The next step I would assume would be to then create a plugin to use
> tx_mail and the partner extension to send bulk mails of selected pages.

It should be able to use different sources of recipient lists. The partner
framework should be one of them.

> With pages selected from the page tree, to be mailed to partner contact
> details selected by criteria such as relationship or contact permission.
> 

O.K. that would be the third step.

> Mailout stats could hopefully be supported by an official stats
> extension one day. I would like to organize a joining of the many TYPO3
> stats extensions when things slow down a bit but a mail stats plugin
> should suffice to help with the replacement or enhancement of direct_mail.

Step 4.

> 
> 
>>
>> C) Stanlis' FE User Registration:
>>
> 
> What do you think about concentrating attention on reworking the partner
> extension to support the MVC model extensions first?
> 

I suggest to concentrate on integration of tx_lib with tx_cal first and the
necessary prerequests for tx_lib at all. (flexform support, language,
resultbrowser, ....) Not to forget the one or other template engine.

> Then partners could be created with specific criteria such as
> relationships and contact permissions with a tx_forms supported partner
> registration plugin.
> 

Right. See a) and b) below.


>> a) A basic configuration that das all the workflow of the registration and
>> is really easy to configure.
> 
> Hopefully this could be covered by the partner registration plugin.
> 

Should be very small itself: email, password, username. Register, email
confirmation, alter, unregister. This is a weekends work.

The texts of email confirmations could come from a regular page content
instead of html-templates. I think of a special content element, that
contains a helptext with the valid markers.


>> b) A second layer that adds configurable fields to the registration
>> process. That is the part that is really time consuming today. It should be
>> devided from a). Differnt styles of templates would be possible here.
> 
> Hopefully the coming forms library will provide a solution for this.
> 

It would have an flexible API that can be used by other plugins to extend
the range of fields. This is the challenge part. Probably based on tx_forms.

>> So enough stuff for today. David I guess this is the kind of coordination
>> of extensions, you are very inerested in. So make it your project. Get in
>> contact with Stanislas. Get in contact with David Brühlmeier. Get in
>> contact with others who need FE users for their own extensions. Make it happen.
> 
> Excellent! It looks like we are on the same wavelength. I am interested
> in what you think about my plans. I will also get David and Stanislas'
> opinion on this thread, and any other direct mail, subscription, or user
> registration extension developers that would like to contribute. With
> the the long term goal of marking the plethora of mail and user
> management extensions obsolete.
> 

Horrido

Elmar