You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Neil Gunton <ne...@nilspace.com> on 2005/08/11 07:03:09 UTC

Re: Tag mismatch

Gerald Richter wrote:
>>I had a minor issue with Embperl 2 thinking there were some 
>>mismatched <UL> and suchlike, whereas these were in fact just 
>>being generated in some conditional/looping code (and so the 
>>tags would obviously not match up if you look at the code in 
>>a linear fashion (as Embperl2 appears to be doing). I just 
>>got around that by changing those cases to [+ '<UL>' +] etc, 
>>in other words they are no longer tags to Embperl but simply 
>>strings. This seems like a cludge but there were only a 
>>couple of cases so it seems like an isolated case, not all 
>>over my code. It would be nice if we could switch off this 
>>kind of overly anal behavior without losing other stuff like 
>>forms processing, but I guess you can't have everything.
> 
> Syntax EmbperlBlocks will disregard _all_ HTML tags, i.e. it will still fill
> your %fdat and [$hidden$] works, but <input ... > will not get anymore the
> value from %fdat.
> 
> The best for you would be, to go to the Embperl/Syntax directory, make a
> copy of EmbperlHTML.pm (let's say EmbperlBasicHTML.pm), remove all
> definition of tables and lists and then add
> 
> Embperl_Syntax EmbperlBasicHTML
> 
> To your httpd.conf
> 
> Gerald

This doesn't strike me as a very elegant solution - what about when Embperl updates come out, where 
you have changed the EmbperlHTML.pm file? Then I would need to go through this file and figure out 
what to change each time. This isn't the way that customization should be done for an application 
framework, imho. I know it would work, and you know the code very well, but I do not really know it 
very well at all and I don't much fancy messing with the Embperl innards.

A better solution, I think, would be to have some setting that could be set at the "user" (i.e. 
developer) level without having to hack the source code.

But I know that's just more work for you Gerald, sorry! ;-)

/Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


RE: Tag mismatch

Posted by Gerald Richter <ri...@ecos.de>.
Neil,

We can make such a BasicHTML syntax a part of the officaly Embperl
distribution, but I don't want to change this before 2.0 release.

So for now do it on your own, make your expericences and if you are lucky
with it send me what you have done and I will incororate it into 2.1

Gerald


---------------------------------------------------------------------------
Gerald Richter            ecos electronic communication services gmbh
IT-Securitylösungen * Webapplikationen mit Apache/Perl/mod_perl/Embperl

Post:       Tulpenstrasse 5          D-55276 Dienheim b. Mainz
E-Mail:     richter@ecos.de          Voice:   +49 6133 939-122
WWW:        http://www.ecos.de/      Fax:     +49 6133 939-333
---------------------------------------------------------------------------
ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
---------------------------------------------------------------------------

  

> -----Original Message-----
> From: Neil Gunton [mailto:neil@nilspace.com] 
> Sent: Thursday, August 11, 2005 7:03 AM
> To: Gerald Richter
> Cc: embperl@perl.apache.org
> Subject: Re: Tag mismatch
> 
> Gerald Richter wrote:
> >>I had a minor issue with Embperl 2 thinking there were some 
> mismatched 
> >><UL> and suchlike, whereas these were in fact just being 
> generated in 
> >>some conditional/looping code (and so the tags would obviously not 
> >>match up if you look at the code in a linear fashion (as Embperl2 
> >>appears to be doing). I just got around that by changing 
> those cases 
> >>to [+ '<UL>' +] etc, in other words they are no longer tags 
> to Embperl 
> >>but simply strings. This seems like a cludge but there were only a 
> >>couple of cases so it seems like an isolated case, not all over my 
> >>code. It would be nice if we could switch off this kind of 
> overly anal 
> >>behavior without losing other stuff like forms processing, 
> but I guess 
> >>you can't have everything.
> > 
> > Syntax EmbperlBlocks will disregard _all_ HTML tags, i.e. it will 
> > still fill your %fdat and [$hidden$] works, but <input ... 
> > will not 
> > get anymore the value from %fdat.
> > 
> > The best for you would be, to go to the Embperl/Syntax 
> directory, make 
> > a copy of EmbperlHTML.pm (let's say EmbperlBasicHTML.pm), 
> remove all 
> > definition of tables and lists and then add
> > 
> > Embperl_Syntax EmbperlBasicHTML
> > 
> > To your httpd.conf
> > 
> > Gerald
> 
> This doesn't strike me as a very elegant solution - what 
> about when Embperl updates come out, where you have changed 
> the EmbperlHTML.pm file? Then I would need to go through this 
> file and figure out what to change each time. This isn't the 
> way that customization should be done for an application 
> framework, imho. I know it would work, and you know the code 
> very well, but I do not really know it very well at all and I 
> don't much fancy messing with the Embperl innards.
> 
> A better solution, I think, would be to have some setting 
> that could be set at the "user" (i.e. 
> developer) level without having to hack the source code.
> 
> But I know that's just more work for you Gerald, sorry! ;-)
> 
> /Neil
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org