Seeking Clarification on Validation for Emancipation from Frustration
Permalink 1 user found helpful
Ok, so I created a custom user attribute, and it's working fine...well, except for the validation.
The docs here...
http://www.concrete5.org/documentation/developers/attributes/types...
...state, regarding the validateForm() function...
"This is run when a developer or concrete5 has decided a particular attribute needs to be validated before it can proceed. This function should return false if the $data is incomplete, or true if it validates."
It doesn't seem to be quite that simple, however. In fact, it seems that user attribute validation occurs ONLY if the attribute is flagged as "required".
Am I missing something, or is that how it's supposed to work? It seems perfectly reasonable to want to validate a field without requiring that it be completed.
In other words, I might want to provide an optional "alternate_email" (or whatever) field. The user is not required to enter a value, but IF they do, I'd like to validate it. It SEEMS that's what the validateForm() function should do, but it doesn't.
Now, I'm sure I can work around this somehow, but I want to make sure I'm not overlooking or misunderstanding something.
Thanks for any insights,
-Steve
The docs here...
http://www.concrete5.org/documentation/developers/attributes/types...
...state, regarding the validateForm() function...
"This is run when a developer or concrete5 has decided a particular attribute needs to be validated before it can proceed. This function should return false if the $data is incomplete, or true if it validates."
It doesn't seem to be quite that simple, however. In fact, it seems that user attribute validation occurs ONLY if the attribute is flagged as "required".
Am I missing something, or is that how it's supposed to work? It seems perfectly reasonable to want to validate a field without requiring that it be completed.
In other words, I might want to provide an optional "alternate_email" (or whatever) field. The user is not required to enter a value, but IF they do, I'd like to validate it. It SEEMS that's what the validateForm() function should do, but it doesn't.
Now, I'm sure I can work around this somehow, but I want to make sure I'm not overlooking or misunderstanding something.
Thanks for any insights,
-Steve
Thanks for the info, 12345j. I didn't bother to test this particular issue under the forthcoming 5.6 release. It's a 5.5 site that I'm working on. I'll give it a try, though, to see if it really is addressed in 5.6. If so, perhaps I can convince the client to update to 5.6.
-Steve
-Steve
I dont know what this means but I vote this as the best headline for a discussion EVER!
Seconded!
I agree that this is the best title evar.
Here's a not-so-brief explanation: you can create custom attribute types for c5, in case you need to provide more complex fields for file properties or page properties or user registration/profile properties. For example, I've created a custom "file upload" attribute type in the past (http://c5blog.jordanlev.com/blog/2011/12/file-upload-attribute-for-... ) because a site I built for a client required that people upload a certification PDF file before they were allowed to be registered as members. I wanted to create a User Attribute so that this file upload thingy would automatically appear on the site's registration page, but C5 doesn't provide such an attribute type (it only provides things like textbox, select list, image, etc.).
So I created my file upload attribute type which lets you create a new User Attribute on registration forms that require new users to provide a file for upload. Ideally I would want this attribute type to validate different kinds of errors that could occur. For example, if the user doesn't provide a file at all, then don't let them register. If they provide a Word Doc instead of a PDF (or any other kind of non-PDF file), tell them it's the wrong kind of file. If they try to upload a file larger than 2MB, tell them it's too large.
BUT, due to the way C5 works (or worked, up until 5.6 which as 12345J points out appears to have addressed the issue), there's no way to tell users that the file is of the wrong type or that it's too big -- C5 only has you tell it "yes it's valid" or "no it is not valid", and what's even worse than that is C5 always tells the user "Data is required" if you say "no this isn't valid". In other words, C5 assumes that the only validation you would perform on a custom attribute type is to check if it was required or not.
It is *very* frustrating because building custom attribute types is so poorly-documented to begin with... once you get this far deep into the rabbit hole you've spent so much time, that when you realize you can't do this thing which is kind of basic and makes a big difference to your users in many situations... it makes you want to pull out whatever hair you have left.
-Jordan
Here's a not-so-brief explanation: you can create custom attribute types for c5, in case you need to provide more complex fields for file properties or page properties or user registration/profile properties. For example, I've created a custom "file upload" attribute type in the past (http://c5blog.jordanlev.com/blog/2011/12/file-upload-attribute-for-... ) because a site I built for a client required that people upload a certification PDF file before they were allowed to be registered as members. I wanted to create a User Attribute so that this file upload thingy would automatically appear on the site's registration page, but C5 doesn't provide such an attribute type (it only provides things like textbox, select list, image, etc.).
So I created my file upload attribute type which lets you create a new User Attribute on registration forms that require new users to provide a file for upload. Ideally I would want this attribute type to validate different kinds of errors that could occur. For example, if the user doesn't provide a file at all, then don't let them register. If they provide a Word Doc instead of a PDF (or any other kind of non-PDF file), tell them it's the wrong kind of file. If they try to upload a file larger than 2MB, tell them it's too large.
BUT, due to the way C5 works (or worked, up until 5.6 which as 12345J points out appears to have addressed the issue), there's no way to tell users that the file is of the wrong type or that it's too big -- C5 only has you tell it "yes it's valid" or "no it is not valid", and what's even worse than that is C5 always tells the user "Data is required" if you say "no this isn't valid". In other words, C5 assumes that the only validation you would perform on a custom attribute type is to check if it was required or not.
It is *very* frustrating because building custom attribute types is so poorly-documented to begin with... once you get this far deep into the rabbit hole you've spent so much time, that when you realize you can't do this thing which is kind of basic and makes a big difference to your users in many situations... it makes you want to pull out whatever hair you have left.
-Jordan
I have to take umbrage with your final paragraph. Just because attributes don't do something that you want it to do doesn't make it poorly documented. You link to a page of documentation on attribute types, which in turn links to this:
http://www.concrete5.org/documentation/how-tos/developers/create-a-...
Which is a rather large amount of real-world documentation on this particular feature.
http://www.concrete5.org/documentation/how-tos/developers/create-a-...
Which is a rather large amount of real-world documentation on this particular feature.
I'd have to agree with Jordanlev on this one. If it wasn't for his efforts at helping in the forums and documenting on his blog, MANY of us would have been absolutely and completely screwed because C5 documentation is lacking.
Andrew, your blog is even poorly documented. Whenever you discover something of major importance, it should be big and bold in a section called IMPORTANT BUG FIXES and that should be cross-referenced on the Downloads page for each version so we know what fixes are still relevant. For instance, this:http://andrewembler.com/posts/improving-the-performance-of-zend-cac... I just tried it and... don't know if I just broke my site or if the site just broke because it's C5 and that's what C5 does after a while: break! Of course, there's no date on your blog post so how would I know if it's current or not? I should look at the comments and see if any of them are recent and make a guess based on that? You should put a date on your blog posts. Refusing to put a date on blog posts is the sort of crap bloggers pull who want to get more traffic and don't want their content to appear outdated. That's silly for a blog such as yours which is very much dated information depending on what version of C5 we're at these days. It's relevant information for a topic such as this.
Andrew, your blog is even poorly documented. Whenever you discover something of major importance, it should be big and bold in a section called IMPORTANT BUG FIXES and that should be cross-referenced on the Downloads page for each version so we know what fixes are still relevant. For instance, this:http://andrewembler.com/posts/improving-the-performance-of-zend-cac... I just tried it and... don't know if I just broke my site or if the site just broke because it's C5 and that's what C5 does after a while: break! Of course, there's no date on your blog post so how would I know if it's current or not? I should look at the comments and see if any of them are recent and make a guess based on that? You should put a date on your blog posts. Refusing to put a date on blog posts is the sort of crap bloggers pull who want to get more traffic and don't want their content to appear outdated. That's silly for a blog such as yours which is very much dated information depending on what version of C5 we're at these days. It's relevant information for a topic such as this.
I apologize if that sounded harsh, but I've been struggling with C5 for a few years now and just actually came back from vacation to 2 broken C5 sites (5.5.2.1). A third one is moving very slow. Why? I have no idea. I thought 5.5+ was finally going to fix the slowness. I was very happy at first, but it was a miserable welcome back from vacation.
I do appreciate the hard work and excellent vision of the C5 creators. Certainly, many other options have much worse documentation. I think dating bugs and bug fixes is really important as well as documenting which versions the bug-fixes are good for. When a new version is released, there must be checklist of bugfixes that is completed; it seems like it would only be a matter of going down the checklist and updating the bug fix documentation right at the top, e.g. "NOTE: This is no longer an issue as of version 5.6.x.x." etc.
I do appreciate the hard work and excellent vision of the C5 creators. Certainly, many other options have much worse documentation. I think dating bugs and bug fixes is really important as well as documenting which versions the bug-fixes are good for. When a new version is released, there must be checklist of bugfixes that is completed; it seems like it would only be a matter of going down the checklist and updating the bug fix documentation right at the top, e.g. "NOTE: This is no longer an issue as of version 5.6.x.x." etc.
https://github.com/concrete5/concrete5/blob/master/web/concrete/core...