Conditional Commands Anyone?

But they do constitute a template language. And as such should not just be an ad hoc addition to the parser IMO. This should be an add-on so those who adopt MODx and aren’t first time web site designers, can choose the templating system they want to use to achieve such things.

Even if we design our own that matches our tagging system, and everyone else agrees these are good additions, I still think it should be handled as a template language addition (to core or as add-on) and designed properly, so it can be extended easily into a complete templating language with much more than conditionals. Otherwise, if it were me, it’d be a plugin called ConditionalTags or something.

Quote from: xwisdom at Dec 20, 2005, 02:45 PM

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 agree with you. I don’t think we need smarty either, at least not as the default. If someone wants to work on creating a parser for smarty or any other templating engine I think that would be a great feature to offer but not as a core default.

And I realize that these are very simple tags at this point, I just want to make sure it’s not the first of what will become an overly complicated templating engine which will steal away the simplicity of MODx templating. It’s a slippery slope and I could throw out a few hundred other "why not this too"s and they all make sense individually, but when you’re done you have an overly complicated beast on your hands.

Most CMSs have gone down that road and I think they’re mostly worse-off for it. I was around or PostNuke’s new templating engine that was the beginning of the end for them (if you ask me). Yes it was way more powerful than the old header/footer templates but it was so complicated that nobody wanted to take the time to learn it or use it. I just want to make sure the same thing doesn’t happen to us.

Quote from: xwisdom at Dec 20, 2005, 02:45 PM

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).

Personally I don’t see the harm in having serveral widgets for those who want to use them. Let’s keep it modular and not put things in the core for a slight performance gain. If we start loading easily modular code in the core for performance reasons then there’s no end in sight and we’ll end up with a bloated core.

If the problem with having "several widgets" is that they are confusing or get in the way then let’s find a better way to organize widgets instead of putting what could easily be a widget in the core.

Quote from: xwisdom at Dec 20, 2005, 02:45 PM

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`]]

Personally I still don’t see why we don’t just package a bunch of widgets to accopmlish this same thing and keep them out of the core. Yes it will be a LITTLE bit more processing when they are used but it will be less for all of the pages where they’re not used (which would be most pages I’d think).

Is this:

any simpler for a designer than this?


Overall I’m not as adament about this as I probably sound. It’s probably just a red flag for me because of my PostNuke days and seeing how their overly complicated templating system (which they raved about for a year before it came out) started a slow leak of users that’s never been patched.

Wow that was long. I think I need to get back to work beore it get’s any longer

Dang... I can’t wait to get done with this VOIP deployment...

I would submit that we let it happen exactly as Raymond proposed. We’re definitely not trying to recreate Smarty... just some REALLY simple VERY basic templating constructs that share the same syntax as our other widget "stuff". I also think we should do the Widget route too... that’s exactly what Personalize and MemberCheck do, for example.

If we move forward with the in-built conditional tags, I’d really prefer that it be implemented as a plugin as I’d like them to be an optional component that won’t add to the core API size and memory requirement. Heck I might even use them myself!

But this is definitely another case of where we should encourage cool ideas and exploration, rather than imposing constraints and raising objections before we see the implementation and actually get to see touch and feel it. Likewise it should fall on Raymond to put some code out there for us to look out in a pretty quick manner!

Keep up the great work folks!

As a plugin or some other modular format I think this would be great. And if you strongly feel that it really should be in the core, then that’s okay with me too. I just think we need to be very careful that we don’t take this too far and wind up with a complicated templating solution like every other CMS.

Ok, I’ve seen more hints that this is going to be included in the core, and I am now, more than ever opposed to this. It should be an optional add-on and not part of the standard processing of the system, unless we design a full-scope plan for implementing a language for scripting in tag format. Again, these kinds of things already exist in many forms and to throw a single kind of control experession in as a one-off tag solution is IMO amateurish at best; this is nothing more than a tertiary statement that can already be processed via PHP itself. It would be better to have a way to represent or expose PHP scripting in the tags -- this goes back to the whole argument about templating systems and PHP already being a template language.

Consider something like:

or

Again, these kinds of things already exist in many forms and to throw a single kind of control experession in as a one-off tag solution is IMO amateurish at best; this is nothing more than a tertiary statement that can already be processed via PHP itself.

I think I’ve had enough for one day. I really don’t want to tick off anyone else for today.

From what I see happening here is that our ideas are pulling in two different directions. In the beginning it was fun to write stuff for MODx but now it’s giving me a headache.

I guess it’s time for me to turn this project over to the pros.

Hey everyone, Raymond and I chatted, I apologized for my poor word choice in calling Raymonds tag solution amateurish, and everything is alright. Other than Raymond catching a bit of the flu. We’re all pros here, and I will do my best to avoid offensive posts like this in the future -- I’m just passionate about what I do and love to explore designs via dialog; I think it is very important to the quality of what we produce as a team.

In any case, Raymond and I still love one another and all is well!

Personally, I’d use really simple conditionals like Raymond’s talking about. But then someones gonna want one more thing, then another, then another. Then someone wants Smarty, or patTemplate...

Solution... implement it as a plugin and let anyone bring over ALL the templating languages!

Quote from: rthrash at Jan 18, 2006, 03:12 PM

Solution... implement it as a plugin and let anyone bring over ALL the templating languages!

The system will be designed in such a way that you will be able to do just about anything you want. Conditionals can be added to the database which will then be executed on special calls:

So in the case where you want to use raw php code. you can do just that by creating your own tag.

[[:PHP? echo ’hello world’; ]]
[[:PHP?
echo "look Ma! I’m coding!";
if($cms->isWebLogin()) echo "Hi there!";
]]

The system will only support a few built-in conditional tags. Users will then be able to create their own:

[[:SMARTY? {variable}]]

Let me just point one thing out about writing straight PHP in a template. It’s a great idea and extremely powerful. However, it is also a HUGE security issue. So, this obviously needs to be an optional (preferably non-core) plugin that will not be given out without a hole bunch of warning that using it means that any content editor can write whatever code they want against your server.

The use of something like this in combination with visitor comments could be potentially disasterous.

I know this is all just talk now but I thought I’d get an early warning in.