Introduction/label filtering placeholders

[Bauer]

Per this hint given by troester in the old beta forum...

...in the form intro you can use
{new:here comes text for new forms}
{edit: text shown in existing records (edit+detail)}
http://fabrikar.com/forums/index.php?wiki/forms/

I just tried this - and it works for {add ...}

BUT, apparently "details" is treated the same way as "edit".

Shouldn't that feature be reworked to exclude anything with an {edit: ...} tag when in "details" view - just as it does when adding a new record? If the tag is "{edit ...}" it should ONLY display the text inside the tag when in edit mode, no?

 

[Bauer]

To followup -
This replacement for the getIntro() function in /components/com_fabrik/models/form.php seems to do the trick - if any of the Github gurus would be willing to post as pull request.

I basically just moved the initialization of $intro to the top followed by an if/else condition.

I already tested with both {new ...} and {edit ...} - on the frontend anyhow.

public function getIntro()
{
$intro = $this->getForm()->intro;
if(JRequest::getVar('view')=='details'){
$intro = preg_replace('/{new:\s*.*?}/i', '', $intro);
$intro = preg_replace('/{edit:\s*.*?}/i', '', $intro);
}else{
$match = ((int) $this->_rowId === 0) ? 'new' : 'edit';
$remove = ((int) $this->_rowId === 0) ? 'edit' : 'new';
$match = "/{" . $match . ":\s*.*?}/i";
$remove = "/{" . $remove . ":\s*.*?}/i";
$intro = preg_replace_callback($match, array($this, '_getIntro'), $intro);
$intro = preg_replace($remove, '', $intro);
}
$intro = str_replace('[', '{', $intro);
$intro = str_replace(']', '}', $intro);
$w = new FabrikWorker;
$intro = $w->parseMessageForPlaceHolder($intro,$this->_data, true);
/* $$$ rob 26/01/2011 - this was stopping content plugins from rendering.
* $intro = str_replace('{','[', $intro);
* $intro = str_replace('}',']', $intro);
*/
return $intro;
}

 

[Bauer]

And to followup on my original request in the old forum (a tag for admin).

You can insert this code just after the if/else in my last post, and you now can use an {admin: ...} tag to allow the text to only be seen by Super Users and and Administrators.

$user = & JFactory::getUser();
//8 is for Super User and 7 is for Administrator
if (isset($user->groups[8]) || isset($user->groups[7]))
{
$intro = preg_replace_callback('/{admin:\s*.*?}/i', array($this, '_getIntro'), $intro);
}else{
$intro = preg_replace('/{admin:\s*.*?}/i', '', $intro);
}

 

[troester]

I assume you are bauer-git and you have forked fabrik?
Then you can start a pull request on your own:
goto the fabrik repro, to the file you want to modify, click edit: this will create a new branch in your repro (patch-X)
edit + "propose file change"

About the {admin}: can be difficult because groups 7/8 are coming as Joomla default groups but the user can change them and can have additional admin groups, so hardcoding 7,8 won't be a general solution.
So (just thinking) something like {group7}?
And how to nest it with {edit... ?

 

[cheesegrits]

That's why I suggested a more generic {acccess:X} mechanism, as group ID's are no longer fixed and immutable in 2.5. Also, I'd suggest using access levels, rather than groups, as that's pretty much the whole idea behind access levels in 2.5 ... they control access to "things".

And, as I mentioned before, I'd much rather go with a {tag}...{/tag} method going forward, than {tag: ...}. Just keep the original lines in there for {new:...} and {edit:...} for backward compat, but allow for {new}...{/new} for moving forward.

Also, it'd be nice to implement this as a helper method, so we can use it elsewhere. So, for instance, if Jaanus adds the getOutro() he wants, he can just call the helper method to process the text.

-- hugh

 

[cheesegrits]

Really, we're talking about building our own little tag based markup parser, similar to something like bbcode (what these forums use for [foo] tags). So a good place to start would be to hunt around for a pubic domain class that does it. No point reinventing the wheel.

-- hugh

 

[cheesegrits]

Here's one I've used in the past, when building forum software, which works very well. Handles nested codes, and has all the callback features we'd need. So [access=4]blah [new]whatever[/new] blah blah[/access] would work, and would be very easy to implement.

It's a bit heavyweight, there's probably a lighter one out there, as this is a very common task in PHP. Or we could take this one and run with it, chopping out all the stuff we don't need (like the string mode).

http://www.christian-seiler.de/projekte/php/bbcode/doc/en/chapter9.php#example

-- hugh

 

[Bauer]

Yeah well, I need to try some other solution - as I just discovered this morning that my "fix" does not work in List Introductions. Nor will the other built-in {new: ...} and {edit: ...} tags. The function to check for those tags is only called in form.php - but not list.php.

Something to remember when you get around to this planned tag parser, Hugh. Hopefully they will work throughout Fabrik.

 

[cheesegrits]

Well yeah, we only check for new/edit in form intros, as that concept has no meaning in list intros.

At the moment there is no getIntro() methid in the list model, we just run the param itself through placeholder replacement in the base list view:

		$this->table->intro = $w->parseMessageForPlaceHolder($item->introduction);

So if we want to do anything else to it, we just need to add a getIntro() in the list model, and handle any additional processing there. Which is why I suggested implementing any kind of tag parsing as a helper method, so it can be called from anywhere.

The best helper to put it in would probably be parent.php, as that's where the existing placeholder substitution code is.

I realize the whole extensible nested tag parsing thing is further than you wanted to go. Your best bet is probably to simply run your own fork with the admin/user specific changes you wanted, until I get time to whip up a parser. At which point adding any kind of new tag would become very simple.

I know running your own version of the code isn't ideal, and I don't recommend it for anything involving significant changes to core code. But for this kind of small tweak which is unlikely to generate support confusion (where your changes may cause knock on bugs), github makes it incredibly easy to run your own fork, and still keep it up to date and merged with the master.

-- hugh