Hello all,
I'm currently developing a CLI plugin which would requires a email address as a key in the plugin yaml. Something like this fragment:
users:
j[email protected]:
fullName: John Doe
pseudo: doe
category: noobs
j[email protected]
fullName: Bond, James Bond
pseudo: 007
category: wizard
Editing such a yaml file with an editor is not a problem and despite the de-facto dotted notation of the email address keys, reading, parsing and using the yaml infos works like a charm.
It's another story when it comes to the point to draw the plugin blueprint to allow the maintenance of the yaml plugin params file thru the admin plugin. Designing the entries for the corresponding field is easy with a list and a key fields type :
users:
name: users
type: list
btnLabel: Add a user
key: emailAddr
fields:
.emailAddr:
type: key
label: User e-mail
validate:
required: true
.fullName:
type: text
label: User full name
.category:
type: text
label: User category
The problem arises when saving the entered values. For reasons perfectly understandable with regards to the nature of yaml language, the email address value is exploded into sub-key fields. Grav admin also doesn't like the @ when reading the existing values and escape the @ as an html entity.
My first question is then: is there any regular Grav feature to deal with this case? If not regular an standard, is there a possibility to call a user-defined function whenever the data are read and saved to apply a transform to the field data, example storing johnDOTdoeATfoobarDOTcom and restoring that to normal email address at time of reading the data. Writing the function is indeed not a problem, the question is how to attach it to the field in the plugin blueprint.
If there is no such possibilities, an alternative would be to change the design of the plugin yaml file (and the corresponding plugin code) as :
users:
-
email: j[email protected]:
fullName: John Doe
pseudo: doe
category: noobs
-
email: j[email protected]
fullName: Bond, James Bond
pseudo: 007
category: wizard
This is as easy as the previous form to represent in the plugin blueprint, but the question there is "how to guarantee the uniqueness of the email field among siblings list fields?"
I've been extensively, but unsuccessfully so far, browsing the documentation and any piece of code available to find a similar use case. Any indication pointing me to the right direction would be much appreciated. Indeed this is not a blocking issue for my plugin to work, but I really prefer elegant things whenever possible...
Have a good day.
Michel.
PS1: sorry for any mistake in my English, not my mother tong...
PS2: before anyone ask: the plugin allows to post a Grav page from a mail. Actually it is done, works ok, has many options for security and flexibility and offer as a side feature an Antimatter blog-like page type to be usable out-of-the-box. I'm now packaging it to submit it to the Grav team for release as a gpm Grav plugin.