Quote from: bS at Oct 09, 2006, 11:10 AM
1.0 >:
I want to take 1.0 out of the discussion, we know everything will be better then 
Absolutely not; nothing will be better then if we don’t make it part of the discussion. IMO, nothing is more important to this project’s future than paving a smooth path from where we are to where we are going. Without that part of the discussion, there is no common vision or goal to achieve, and the solutions we come up with will be inconsistent, and could potentially lead us in directions future releases would never be able support, or to confusing changes in how to approach specific problems with implied MODx best practices (implied by implementation of existing components).
Quote from: bS at Oct 09, 2006, 11:10 AM
pre-1.0:
I agree to the fact that the conditionals and the modifiers should be a seperate add-on/plugin, the only thing i’m concerned about is all the rogue templating solutions (like my own) popping up. There’s no default solution that will allow a acceptable degree of freedom for designers. All snippet developers are creating their own templating solution or the templating involves using many small snippets to get things done.. and that makes it very frustrating for the average user. The issue with conditionals are now generally solved by putting them in your snippet code, thus in many cases limiting the designer and creating ’unneeded’ extra code for the snippet author.
If we go with the templating by add-on/plugin solution please point the MODx community into the same direction of how to do this. And IMO the way it’s done now (limiting design + overhead in snippet code) is not very attractive. I stuck with MODx because I know what is possible with a little extra coding (as a coder), but think of all the people who hate touching code but do know how to spice a site up and they get hit in the face by the way MODx limits their view.
First, I still see no reason to add any templating features to the MODx parser. The thing that sold me on MODx was the simple approach to templating it took, and the profound way it encouraged me as a developer to break down the logic and presentation into small, manageable parts, in whatever way was best for the stakeholders of the site I am working on. I’ve done this quite successfully without adding any additional parsing overhead to MODx. It’s just a matter of organization and planning the interface so less-technical users can easily modify just the parts they want to be able to without messing up the rest.
I would venture to say the only real problem here is the inability to easily import/export groups of related components together, including example pages on which the components are implemented as an example of usage. With this feature, I think the model of using many small components is best solution, and is exactly what I’m trying to achieve. Modularity. Re-use. Loose-coupling. These are all important concepts of extensibility and interaction between components; with very clear and specific purposes, and without a zillion configuration options, MODx can encourage each component to be more efficient and allows it to focus on doing a single task, and doing it extremely well.
Quote from: davidm at Oct 09, 2006, 10:40 AM
If I understand correctly, that would mean conditionnal testing, filters and modifiers would happen before the document is even parsed ? Directly during data retrieval from the DB ?
No, it simply means there are methods already available as part of the xPDO core API that allow you to use modifiers/filters to format the data in various ways, based on what type of data it is (string, int, float, datetime, timestamp, date, enum, etc.). And using those API methods to create generic components that can allow designers to easily add/change/remove the modifiers is trivial.
Quote from: davidm at Oct 09, 2006, 10:40 AM
I do understand why filters and modifiers would be processed that way, but I have more trouble understanding the concept for conditionnal testing. Would it mean conditionnal testing would be somewhat like using @EVAL for a TV ?
No, it simply means there would not be a dedicated tag syntax for conditionals. Condition behavior can easily be achieved by creating a snippet for each kind of conditional logic you want to apply, e.g.
[[IF-ELSE? &if=`[[IsMember? &group=`foo`]]` &do=`[[foo]]` &else=`[[$bar]]`]]
This will test the if result of IsMember and if true, execute the snippet `foo`, else output the content of the `bar` chunk. You can create snippets like this, with a great deal of flexibility and control, to handle just about any conditional logic anyone can think of. And most importantly I think, it can be easily customizable for individual deployments by simply modifying a snippet, instead of changing something in the parser.
Likewise, with the modifiers/formatters, you can easily do something like this with xPDO and a couple of very simple snippets:
[[MyOnlineReport? &reportMode=`card`]]
<p style="postion: absolute; top:10px; left: 100px;width:600px;color:#000;font-size:86%;font-weight:bold">Click your data to go to the edit page.</p>
<p style="postion: absolute; top:10px; left: 450px;width:200px;font-size:86%;"><a href="[+xReferrer.href+]">Return to previous page</a></p>
<div id="pvwName">
[[xGet? &objClass=`Person` &fields=`first_name||middle_name||last_name` &tpl=`MyOnlineReport.person`]]
</div>
<div id="pvwID">
[[xGet? &objClass=`Person` &fields=`member_id,re:/([A-Z0-9]{3})([A-Z0-9]{4})([A-Z0-9]{3})/,$1-$2-$3` &tpl=`MyOnlineReport.member`]]
</div>
<div id="pvwAddress" onclick="window.location='[~82~]'" class="editable">
[[xGet? &objClass=`Address` &objKey=`address` &fields=`street||city||state||zip` &tpl=`MyOnlineReport.address`]]
</div>
<div id="pvwExp">
[[xGet? &objClass=`Member` &objKey=`member` &fields=`expire_date,%m/%d/%y` &tpl=`Preview.expires`]]
</div>
<div id="pvwPhone" onclick="window.location='[~82~]'" class="editable">
[[xGet? &objClass=`Phone` &objKey=`primary_phone` &fields=`number`]]
</div>
<div id="pvwAllergies" onclick="window.location='[~61~]'" class="editable">
[[xGet? &objClass=`Allergy` &fields=`type` &tpl=`MyOnlineReport.allergy-pvw`]]
</div>
<div id="pvwAlert" onclick="window.location='[~60~]'" class="editable">
[[xGet? &objClass=`MedAlert` &fields=`alert` &tpl=`MyOnlineReport.med_alert-pvw`]]
</div>
<div id="pvwBlood" onclick="window.location='[~82~]'" class="editable">
[[xGet? &objClass=`Person` &fields=`blood_type` &tpl=`Preview.blood_type`]]
</div>
This is an example from one of the first sites I deployed using xPDO. I created a snippet (`MyOnlineReport`) which retrieves all the data for the report. Then I created xGet to be able to manage the output from the various data objects on a per page basis, using formatting modifiers based on the xPDO API, as well as chunks serving as templates in which to place the output. In this way, I can create totally different views of the same data, using the same snippets with only slightly different parameters. The same thing could be done for simple db result sets with a slightly different version of this sample xGet snippet.
Quote from: davidm at Oct 09, 2006, 10:40 AM
What would it mean from a designer’s perspective ? Do you have an example of what steps or code would be needed to achieve the same things the new parser is doing now (I confess I am curious !) ?
That’s a lot of questions, I realize... Personnally, what I like about conditionnal tags is you can build things in the context of a template. Not to mention tags are html-like which is nice for designers 
Right, nothing different there. Slightly different tag syntax is all. Consistent with the rest, and simple.
MODX Staff
MODX Staff
