Conditional Commands Anyone?

Hi guys,

What do you make of these?

[[:SECURE?
&groups=`webusers,contacts`
&protected=`
This is the secured Text. Only user groups webusers and contacts will be able to access this area
`
&default=`
This is the default test
`
]]

[[:IIF?
&condition=`true`
&true = `This is true`
&false = `This is false`
]]

[[:CHOOSE? &index=`4`
&1=`This item #1`
&2=`This item #2`
&3=`This item #3`
&4=`This item #4`
]]

As mentioned on the IM, I think the added flexibility and syntax is a major boon over the existing Display/Input widgets. The choose is a select-list picker. The IF is functionally a nested snippet call, and the SECURE is basically my membercheck wrapped in a differnt shell that should be in the core anyway.

Gives us yet another means to the same end, and allows us to go farther towards emulating a building style that makes devs and designers comfortable.

It could be criticized as additional bloat, but there IS such a thing as "good fat".

While working on the new manager I found out that it was kinda difficult at times to just rely on
placeholders to display conditional text inside a template. For example, let’s say I want to display the New user menu link is the user has the role new_user asssigned. To get it to work I would have to write PHP code to display the link for the new user.

As a result of this I thought it would be much easier to have these contidional tags. Sure the same thing can be done using 5 or 4 widgets but that’s something a simple task would not require.

[[:IF-COMPARE? &value=`` &equal=`` &then=`` &else=``]]

[[:IF-NULL? &condition=`` &then=`` &else=``]]

[[:IF-ROLES? &roles=`new_user` &then=`` &else=`` ]]

[[:IF-GROUPS? &groups=`` &then=`` &else=``]]

[[:IF-LOGIN? &context=`manager|web|any` &then=`` &else=``]]

[[:CHOOSE? &index=`indexname1` &indexname1=`` &indexname2=`` ]]

Usage Example:

[[:IF-ROLES? &roles=`new_user`
&then=`
<a href="">New User</a>
<a href="">Edit User</a>
`
]]

[[:IF-LOGIN? &context=`web`
&then=`
Hello [[++cms_login_id]], welcome back
[[:IF-GROUPS? &groups=`WebUsers`
&then=`
You belong to the Web user group!
`
&else=`
You do not belong to the Web user group!
`
]]
`
]]

The latter example will display a greeting message if the user is logged in. No need to write PHP code!

PS. This means that we will no longer be needing the [[:SECURE]] tag as it is replaced by [[:IF-ROLES]],[[:IF-GROUPS]] and [[:IF-LOGIN]] tags

I’m all for it... sounds great and is something non-coders can easily grasp.

Looks good to me.

But let me throw something out. This seems to be our first step away from a tag system toward a templating engine. This is starting to look a lot like smarty to me. Would it be best to look at maybe implementing some existing templating engine like smarty and adapting it to our needs instead of writing our own templating engine?

I’m definitely not saying that we should go with smarty or anything similar, I’m just saying we should consider what we’re getting ourselves into and see if there might be an easier way to reach our goals. In a similar way to what Propel promises do for us with the DB and API.

The one thing I definitely don’t want to do is to greatly complicate the template design process which is probably what would happen with something like smarty. I do want to see more powerful features like this become available as long as they’re optional. I’ve used smarty and have not been especially impressed because they have added so much functionality into it that it’s become it’s own programming language and for many things it’s it’s eaiser to stick with PHP than to use Smarty, which defeats smartys whole purpose.

Optional is a good thing. I don’t think there would be anything that keeps folks from doing it the old fashioined way. This would just give us some basic Smarty-like capabiliites in the same syntax as the rest of the system. Is that a fair assessment Raymond?

You know, is there any reason this should be built into the core? With the new parser couldn’t we easily implement all of these features and more as snippets? I’d rather see an optional package of "Advanced Template Design" snippets then have this built into the core.

The one thing that seems to bring the most people to MODx is the easy templating as opposed to Mambo, Typo, Nukes and others. The beautiful thing about MODx templates in that you can create them in any HTML editor. But if we allow too much logig to be done at the template level instead of the snippet level then we run the risk of having another complicated templating system just like the rest.

People are going to get the output they want and the logic to do it has to be somewhere. The question is do we want the login in the snippets or in the templates? I tend to think it’s best to keep it in the snippets and keep the templates as close to pure HTML as possible.

Like I said I don’t reall have a problem with it as long as it’s not required. But if we offer it then people will use it in the available templates and the documentation will have to reflect it and all of the sudden we’re turning off a bunch of people who just want a pure HTML template without the extra complication.

Okay so I’m just going to keep talking

With some of the ideas for widgets and modular "pseudo compilers" you could easily implement multiple templating engines and even use multiple engines in the same site.

Maybe we should eventually have a default MODx template engine and a Smarty template engine or an advanced MODx template engine. I’ll have to think about about exactly what ramifications this would have in the end but I’m pretty sure it’d be possible.

This is exactly where I want to go Adam, though I also have some ideas for plugins that would allow us to easily add some extensions to our own templating syntax without mucking with the core.

As for the original idea, I do not like the hardcoded object names in the tags, nor the idea of starting to create a library of conditionals and other commands that would indeed turn us into a complex templating system like Smarty. You know how much I hate to reinvent the wheel, so I’d have to say I agree with Adam. Let’s offer Smarty and other templating engines as optional add-ons to MODx. This would extend our audience and flexibility without complicating our core product and increasing development tasks with things that can be done with already existing systems.

This is much the same approach I’m continuing with on my Propel integration/refactoring; utilizing what’s already been done (more in a Propel targeted thread).

I’m are not trying to create another Smarty or template language system. What I’m trying to do is make things a little easier for template designers. We don’t need smarty at this point. These tags are are just some simple swicthes that outputs a value based on a condition. I would not want to use widgets for this purpose as it would require several widgets or a more complicated structured.

These tags will not get in the way of any designer. They either use it or leave it alone. Besides they reuire a few lines of codes. No huge byte size or processing overheads. The way I see it they will be processed much faster that Widgets (similar speed when compared to placeholders).

Before we decided to rule against these conditional tags lets ask ourselves how easy is would be for a developer/designer to secure a section of his/her page?

Posible solution:
1) Use Placeholder to output the value when the user logins - Content is not visible in design mode
2) Use a widget to output the text or a chunk - Requires from php and API knowledge
3) User a TV to output the value and use @EVAL to test if user is logged in
4) Use the new [[:IF-LOGIN]] tag - no need for php or a widget or a tv. Just a simple logical tag.

[[:IF-LOGIN? &then=`Your access code is 9649-223423-2323`]]