in reply to Re^11: Thanks to Ikegami, Chromatic & Corion
in thread Thanks to Ikegami, Chromatic & Corion

Yes, I know, I heard you the first few million times.

If you are saying that what the plugin returns is searched for aXML tags then you actually agree with me; what a plugin returns is treated as aXML. Not HTML.

All plugins that can return arbitrary HTML are buggy and the others are potentially buggy.

  • Comment on Re^12: Thanks to Ikegami, Chromatic & Corion

Replies are listed 'Best First'.
Re^13: Thanks to Ikegami, Chromatic & Corion
by Logicus (Initiate) on Nov 03, 2011 at 01:33 UTC

    I tend not to put any HTML into the plugin code, but instead send it to the plugin from the document level.

    <ul> <some_list_creating_plugin> <li><some_marker></li> </some_list_creating_plugin> </ul> some_list_creating_plugin => sub { my @list = ['foo','bar','baz']; my $mask = $_[0]; my $result; foreach my $item (@list) { my $maskCopy = $mask; $maskCopy =~ s@<some_marker>@$item@gs; push (@results, $maskCopy); } return join (@results); } output ------ <ul> <li>foo</li> <li>bar</li> <li>baz</li> </ul>

      $maskCopy =~ s@<some_marker>@$item@gs;

      But what if $item was HTML from a database instead of being hardcoded aXML...

        Well you wouldn't want to be putting the <ul> tags in then.

        Ok so...

        If our database looked like this

        pageid int primary key auto_increment, name varchar(255), html text Then (db_get)pages.name="(sqd)name(/sqd)".html(/db_get)

        Then localhost:5000?action=test&name=homepage will be displaying the contents of the html column of the pages db.

          A reply falls below the community's threshold of quality. You may see it by logging in.