Advanced variables? I’ll I have to do is use the same variables and it won’t work:
{if textarea && textarea}
To me, as an experienced coder, this looks like some nasty hard-coded/locked-step functionality (aka hack), in, at least, the custom_fields functionality.
However, I can get around this, by not using custom_fields, etc. But I really felt that the EE people would like to know how basic conditionals were not working in, at least, the custom_fields functionality. Oh, well. Some coders just don’t want to know, to the detriment of their products and their users. :(
Bret, ExpressionEngine template code is not meant to be a full-fledged scripting language; to do so would be an exercise in futility to code and have any semblance of good performance, and this isn’t an area where adding to the conditionals is anticipated. This is one particular spot where the only conditionals the tag is expecting are the ones that are documented.
Your post was moved because this is working as intended; we would normally move such posts from the bug forum to the feature request forum, as there’s merit to the suggestion. But as you are not a licensed user, you do not have access to that forum, and we thought you’d like to be able to engage someone in conversation about your problem, as slapshotw and Sock Puppet have stepped in here to guide you.
Incidentally, it looks like you are trying to create functionality that already exists, in the form of field instructions, since each field can have their own instructions and will be automatically output for you if you use the {field_instructions} variable.
Derek, thanks for the informative response; I appreciate that. However, I don’t think that a full-fledged scripting language is an exercise in futility to code, as many individuals and companies have done so, and done so well. Nor do I think that a scripting language is inherently detrimental to good performance: Python, MEL, SQL, etc.
I like the community forum, very nice. It would be great though to get some kind of indicator of why a post is moved—if it’s not obvious, that is. I hope there is currently a suggestion, or someone will be thoughtful enough to make one , either to make the custom_fields handle additional conditionals or, at minimum, to make clear in the user docs that certain functionality, such as in custom_fields, cannot handle any variation in its conditionals from what is shown in the user docs: because from the user docs (as far as I could tell), one would assume that the custom_fields and conditionals are part of a, at least, flexible scripting system.
I was and am using {field_instructions}, but wanted to make conditional adjustments for certain custom fields (see the bottom of my original post if interested). Right now I am using, instead, {exp:query ...} (which requires a JOIN ): so I can use the usual EE conditional functionality.
One other thing—if you don’t mind hardcoding, you can always hardcode the custom fields in there yourself however you see fit. The field names need to be to the effect of field_id_23, but it works. You’ll get proper field names by making a standard entry form and {custom_fields} loop and checking out the output.
The downside is that if you add new fields or reorder them, you’ll have to update them yourself in the SAEF.
sicjedi, comparing EE’s template parser to Python, PHP, or any other interpreted scripting language is comparing apples to apple pie. And by that I mean that, well, ExpressionEngine is a PHP application. And PHP is an interpreted language layer that sits atop a compiled language layer (C). So yes, I absolutely stand by my statement that it’s an exercise in futility and would render EE’s performance completely unacceptable to make its template parser a fully fledged scripted language. Parsing and interpreting text via an interpreted language’s commands via a layer that is parsed and interpreted on top of a layer that is parsed and executed—is beyond reasonable.
It would be great though to get some kind of indicator of why a post is moved—if it’s not obvious, that is.
The forum description text and support policy should be clear enough. Though, as someone fresh to the community, the obvious is not yet obvious, so I apologize for the staff not adding a specific note that would have helped you as a newcomer understand the moderated action. I only responded to rebut the statement made regarding “Some coders just don’t want to know, to the detriment of their products and their users. :(” Nothing could be farther from the truth, and an examination of our products’ record in conjunction with bug reports and feedback will bear this out.
to make clear in the user docs that certain functionality, such as in custom_fields, cannot handle any variation in its conditionals from what is shown in the user docs
Thank you for the feedback, we do appreciate new users’ comments on what works in the user guide and what does not. For your future use of ExpressionEngine and the user guide, you can take this to mean that if you do not see it mentioned in the docs, it’s not intended, and probably will not work. Obviously, we cannot anticipate all syntax that goes counter to what is demonstrated, and a user guide full of “don’t do this” “don’t do that” for any product would be much more difficult to read than our current approach which simply tells and shows what you can do.
One other thing—if you don’t mind hardcoding, you can always hardcode the custom fields in there yourself however you see fit. The field names need to be to the effect of field_id_23, but it works. You’ll get proper field names by making a standard entry form and {custom_fields} loop and checking out the output.
Hey slapshotw,
What me hardcode? That’s rare. Though I did see that suggested in the user docs.
In my SQL statement, I just select the “field_id” and use that to to create the name of the fields I use, something like:
{exp:query sql="SELECT field_id, field_label, field_name, field_instructions, field_type, field_required FROM exp_weblog_fields INNER JOIN exp_weblogs ON exp_weblog_fields.group_id = exp_weblogs.field_group WHERE exp_weblogs.blog_name = 'calendar_groups' ORDER BY field_order"} {if field_type == "text"} <input type="text" id="{field_name}" name="field_id_{field_id}" value="" /> {/if} {/exp:query}
PS: You can ignore the INNER JOIN and all tbe extra stuff in the SQL statement; I just included it in case somebody finds it useful.
...ExpressionEngine is a PHP application. And PHP is an interpreted language layer that sits atop a compiled language layer (C). So yes, I absolutely stand by my statement that it’s an exercise in futility and would render EE’s performance completely unacceptable to make its template parser a fully fledged scripted language.
You could create your parser in just about any language you want, C or C++ for instance. Then hook into it from PHP; for example, using exec.
Nothing could be farther from the truth, and an examination of our products’ record in conjunction with bug reports and feedback will bear this out.
Though relevant information is usually available at some location—like the Forum, Wiki, and Knowledge Base—I do wish, from my limited experience with EE so far, that the user docs were more complete… that critical information exposed in those other locations be reflected back to the user docs as appropriate. For example, I wish the user docs, which I would naturally view as the definitive description of EE, had this very important fact:
For your future use of ExpressionEngine and the user guide, you can take this to mean that if you do not see it mentioned in the docs, it’s not intended, and probably will not work.
Hmmm… That sounds like to me that the system is not flexible, but I know it is in many areas. The perfect case in point is in what this thread is about: where conditionals are extremely flexible and customizable, but not in the case of custom_fields. I really feel that this information should be made clear in the user docs. Otherwise, how would people know where some things (eg: usual conditionals) are flexible and customizable and where other things (eg: custom_fields conditionals) are not? Even just a simple sentence would suffice, just to be clear.
You could create your parser in just about any language you want, C or C++ for instance. Then hook into it from PHP; for example, using exec.
For a distributed app, this would limit our target audience severely. Thanks again for the suggestions though, as I mentioned I don’t think it’s a bad idea or performance limiting to allow dynamic conditionals in this tag, it just wasn’t originally designed to do so.
, either to make the custom_fields handle additional conditionals or, at minimum, to make clear in the user docs that certain functionality, such as in custom_fields, cannot handle any variation in its conditionals from what is shown in the user docs: because from the user docs (as far as I could tell), one would assume that the custom_fields and conditionals are part of a, at least, flexible scripting system.
