[TYPO3-ect] TYPO3ext: direct_mail mergers & acquisitions
David Toshack
david at vaultin.com
Mon Oct 23 07:50:13 CEST 2006
Elmar Hinz wrote:
> 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?
I love this idea! A generic tt_news type framework in tx_articles and
tx_cal would be a great asset to TYPO3! I will try to drum up some
support for this with the tx_cal developers.
>>> 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.
+1
Also something like this would be good:
$mail->sendType(SMTP) type functionality so that we could include some
cwt_community and hoicommunity features with:
$mail->sendType(internal).
> I specialized bulkmailer would use tx_lib_mail, but needs an independent
> extension. Maybe tx_bulk? That's where cronscript etc. is included.
+1
>
>> 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.
+1
Again taking some functionality from the community extensions, maybe
some buddy list type functionality could be shared with the bulk mail
feature for sending to a list of users.
>> 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.
>
+1
>>
>>> 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.
+1
I will see what interest I can drum up with tx_cal developers.
>> 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.
+1
>>> 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.
Should this fit under the tx_party umbrella somewhere? Maybe tx_party_user?
>>> 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.
>>
I have emailed most of the fe_user and mail extension developers about
this concerted effort. I'm not expecting any overnight results. We
really need the tx_party and tx_form development to level out a bit
before we put too much effort in, just thought it would be good to get
peoples brains ticking over about it.
Cheers,
David
More information about the TYPO3-team-extension-coordination
mailing list