Jump to content

Custom multi-column Fieldtype + Inputfield - extending for multi language usage?


Gadgetto
 Share

Recommended Posts

Hi,

for my GroupMailer module I've created a custom Fieldtype + Inputfield module which provides multi-column field values. The first field column is a visible text field and there are some other columns which are not presented to user (they are rendered as hidden form fields).

262017940_Bildschirmfoto2019-02-20um19_42_04.png.0d61e10a7761a26218c16bc01c60aea4.png

This is the database schema:

$schema['data'] = 'text NOT NULL'; // we're using 'data' to represent our 'subject' field
$schema['sendstatus'] = 'tinyint NOT NULL DEFAULT 0'; // message send status
$schema['recipients'] = "int(10) unsigned NOT NULL DEFAULT 0";  // recipients counter
$schema['sent'] = "int(10) unsigned NOT NULL DEFAULT 0";  // sent counter
$schema['started'] = "int(10) unsigned NOT NULL DEFAULT 0";  // message sending start
$schema['finished'] = "int(10) unsigned NOT NULL DEFAULT 0";  // message sending finished

This are the ___wakeupValue and ___sleepValue methods:

  Reveal hidden contents

Now I try to extend this Fieldtype/Inputfield to provide multi language features.

Only the first value ("data" which represents the "subject" field) should be/needs to be multi language!

I had a look at the built in Fieldtypes (e.g FieldtypeText & FieldtypeTextLanguage) which provides multi language support but I couldn't find a similar case (multi-value field with language support). All built in Fieldtypes are single-value fields.

I know this is a very "general" question but maybe somebody could push me in the right direction?

Link to comment
Share on other sites

I' really stuck here guys... ? Documentation is no help. Comparing with other multi-language fields doesn't help because they are all single-value fields.

Here are the full sources of my multi-value input field:

FieldtypeMessageMeta.module.php

  Reveal hidden contents

FieldtypeMessageMetaLanguage.module.php

  Reveal hidden contents

MessageMeta.php

  Reveal hidden contents

InputfieldMessageMeta.module.php

  Reveal hidden contents

 

 

 

Link to comment
Share on other sites

I'm not really getting what the question is, although I haven't looked at your code in full.

  On 2/26/2019 at 6:19 PM, Gadgetto said:

Comparing with other multi-language fields doesn't help because they are all single-value fields.

Expand  

Are you sure about this? What do you mean by multi-language fields? Maybe install the multi-lingual site profile and see how things work? For instance, the field images works fine as a multi-language field and it is a multi-value field. I think I'm just not getting the question.

  On 2/26/2019 at 6:19 PM, Gadgetto said:

Here are the full sources of my multi-value input field:

Expand  

if you Fieldtype is meant to store multiple values for the same page (meaning multiple rows in its database table for the same field on the same page) , then this code is not correct:

  On 2/26/2019 at 6:19 PM, Gadgetto said:

class FieldtypeMessageMeta extends Fieldtype {

Expand  

In that case, you'll need to extend FieldtypeMulti. However, I may have misunderstood what you mean by multiple values. For instance, if you meant multiple database columns on a single db row, that's something different.

  • Like 1
Link to comment
Share on other sites

  On 2/26/2019 at 6:19 PM, Gadgetto said:

Here are the full sources of my multi-value input field:

Expand  

Hi @Gadgetto I am sorry for not being able to help but could you please make your thread more readable by "hiding" long code in "Spoiler" blocks (which can be added by clicking on the "eye icon" in the toolbar of this RTE)? 

Link to comment
Share on other sites

  On 2/26/2019 at 9:12 PM, szabesz said:

Hi @Gadgetto I am sorry for not being able to help but could you please make your thread more readable by "hiding" long code in "Spoiler" blocks (which can be added by clicking on the "eye icon" in the toolbar of this RTE)? 

Expand  

Sorry for that, I was indeed searching for the "Reveal hidden contents" feature as I saw this in other post. Just couldn't find it. Thanks!

  • Thanks 1
Link to comment
Share on other sites

  On 2/26/2019 at 6:48 PM, kongondo said:

Are you sure about this? What do you mean by multi-language fields? Maybe install the multi-lingual site profile and see how things work? For instance, the field images works fine as a multi-language field and it is a multi-value field. I think I'm just not getting the question.

Expand  

I don't know how to describe it better. I thought multi-language field is a common term for fields which provide input for different languages (like the InputfieldText/InpufieldTextLanguage).

  On 2/26/2019 at 6:48 PM, kongondo said:

if you Fieldtype is meant to store multiple values for the same page (meaning multiple rows in its database table for the same field on the same page) , then this code is not correct:

Expand  

My Fieldtype is a multi-columns field not multi-rows, therefore FieldtypeMulti won't work (as it is only for multi-row fields).

As I explained in my initial post, I created a Fieldtype which has these columns:

$schema['data'] = 'text NOT NULL'; // we're using 'data' to represent our 'subject' field
$schema['sendstatus'] = 'tinyint NOT NULL DEFAULT 0'; // message send status
$schema['recipients'] = "int(10) unsigned NOT NULL DEFAULT 0";  // recipients counter
$schema['sent'] = "int(10) unsigned NOT NULL DEFAULT 0";  // sent counter
$schema['started'] = "int(10) unsigned NOT NULL DEFAULT 0";  // message sending start
$schema['finished'] = "int(10) unsigned NOT NULL DEFAULT 0";  // message sending finished

The "data" col is a text field and I'd like to provide language support for this col only! (the other columns send status, recipients, ... arte integer fields and don't need language support).

I simply can't find an example Fieldtype which provides similar functionality.

Link to comment
Share on other sites

  On 2/27/2019 at 8:39 AM, Gadgetto said:

I simply can't find an example Fieldtype which provides similar functionality.

Expand  

There is one actually, sort of. Look at the 'images' field in a multilingual setup. 

As you are aware, for truly (I use this word reservedly) multilingual fields, each language has to have its own column. That makes it easy to search the columns in the language you want. However, in your case, since you want only one column to have multilingual features, you have two choices ( + a 3rd not very good one):

  1. Go the route of images fields. In a multilingual setup, the description column of an image field holds each languages' value, saved as JSON. E.g. {"0":"We're gonna need a bigger terminal.","1012":"Wir brauchen einen größeren Terminal.","1013":"Me tarvitsemme isomman päätteen."}. The index of the values are the language ID. In this case, 0= English, 1012=German and 1013=Finnish.The trade off here is searching in one language is limited.
  2. Change your database design pattern. No need to cram things in if they don't fit ?. Let your subject be its own multilingual field and let your other single value data live in their own non-multilingual field. Nothing wrong with that. 
  3. I mention this 3rd option hesitantly. Stick with one field as your are doing but for your data (subject) column create a lookup table for other languages. I am no DB guru but the little I know tells me this 3rd option is not a good design at all.
Edited by kongondo
  • Like 3
Link to comment
Share on other sites

@kongondo Thank you for your hints. In general, I'd like to follow the standard behavior of ProcessWire as closely as possible. So having own "data" columns for each  language would be the best.  I have a Fieldtype "FieldtypeMessageMeta" and try to extend it with "FieldtypeMessageMetaLanguage" - just like other language capable field types do. So an admin can switch between normal Fieldtype and language Fieldtype if necessary.

the longer I think about it, the more uncertain I am if the message subject has to be multilingual at all.

Is it common to automatically send multilingual newsletters? Or is it better to send a separate newsletter for each language?

 

Link to comment
Share on other sites

  On 2/27/2019 at 5:31 PM, szabesz said:

I might have seen a multilingual newsletter once in my life but I might be wrong, so in my experience multilingual newsletters are very rare.

Expand  

I also think so. So I'll let the field be single-language for now and if there are requests to add multilingual feature it can be added later.

  • Like 2
Link to comment
Share on other sites

  On 2/27/2019 at 5:34 PM, Gadgetto said:

So I'll let the field be single-language for now and if there are requests to add multilingual feature it can be added later.

Expand  

Just had a thought, so revisiting this. Going by your screenshot, it seems to me that each message is a unique page, no? If that is the case then you may have your cake and eat it too if instead of storing a message's subject in the 'data' column of your Fieldtype, let it be the page's title? This means for multilingual sites, they can decide to have multilingual messages by using language field title and language textarea (assuming that is where the message body is). You would then need to use 'data' to store something else.

 

Just my 2p.

  • Like 1
Link to comment
Share on other sites

  On 3/3/2019 at 9:19 PM, kongondo said:

Just had a thought, so revisiting this. Going by your screenshot, it seems to me that each message is a unique page, no? If that is the case then you may have your cake and eat it too if instead of storing a message's subject in the 'data' column of your Fieldtype, let it be the page's title? This means for multilingual sites, they can decide to have multilingual messages by using language field title and language textarea (assuming that is where the message body is). You would then need to use 'data' to store something else.

Expand  

You are right! Each message is a unique page. To be flexible, I decided not to use the title field as email subject. GroupMailer will be designed so that each page can be a message. It will only be necessary to add a custom field (FieldtypeMessageMeta) to the corresponding template.
This field type will include the subject field. So it is possible that pages have separate titles and email subject.

Link to comment
Share on other sites

  On 3/4/2019 at 10:08 AM, Gadgetto said:

GroupMailer will be designed so that each page can be a message. It will only be necessary to add a custom field (FieldtypeMessageMeta) to the corresponding template.
This field type will include the subject field. So it is possible that pages have separate titles and email subject.

Expand  

Gotcha.

Link to comment
Share on other sites

Based on your description I feel like you're tackling the problem from the wrong end. You're actually trying to do what was requested from MarkupSEO ages ago: Just adding a single field to a template, but getting a whole bunch of fields in the process. In my opinion either let people add all fields to their templates  or even better have an own template and just store the metadata there. Sadly it took quite a few month until the latter option was actually added properly, but now we have it: 

https://processwire.com/blog/posts/processwire-3.0.73-and-new-fieldset-types/#fieldset-page-fieldtypefieldsetpage
https://processwire.com/blog/posts/processwire-3.0.74-adds-new-fieldsetpage-field-type/

Edit:

And some more context from the time I initially proposed the idea (I've no idea if Ryan actually knew this, but it's basically what I proposed): 

 

  • Like 2
Link to comment
Share on other sites

@LostKobrakai FieldtypeFieldsetPage looks great - didn't even know this exists! Thanks for this hint!

Using a template for configuring/defining a GroupMailer message page was my initial intention. But wouldn't that be too inflexible? Wouldn't it be better if the dev could use any template he likes just by adding a single field? It would also allow to "convert" any existing page to a GroupMailer Message on the fly.

I'd like to hold the Module as flexible as possible but also easy to setup. The longer I work on the project, the more uncertain I will be about the implementation...

Link to comment
Share on other sites

That's what FieldtypeFieldsetPage would allow you to do. Create the field on installation of your module (and update/delete it from your module; It's not to be edited by the user) and the user would just need to add that field to whatever template needed.

Link to comment
Share on other sites

  On 3/4/2019 at 12:44 PM, LostKobrakai said:

That's what FieldtypeFieldsetPage would allow you to do. Create the field on installation of your module (and update/delete it from your module; It's not to be edited by the user) and the user would just need to add that field to whatever template needed.

Expand  

I need to have a look at this Fieldtype and how this is implemented. I currently don't fully understand how this is meant to be used.

Link to comment
Share on other sites

GroupMailer needs a lot of meta data like some send counters, status-flags, send/finished dates and so on - all meta fields are hidden fields only and not editable by the user. The custom Fieldtype I created has all these columns packed in one field. Using  FieldtypeFieldsetPage would mean that I create separate fields for each of these meta columns (if I understand right). Wouldn't this have a performance impact. Instead of using a single (multi-column) field I'd need to use many separate fields.

Link to comment
Share on other sites

Sure has, but it's what you do with most everything else in processwire as well. Are the read/write patterns really that demanding that it would matter? 

But if only one field of yours is multi-language I feel like it should be quite possible to adapt existing patterns from other fieldtypes. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...