search

power-media / prado3

Automatically exported from code.google.com/p/prado3
Other
0 stars 0 forks source link

TStyle does no accept style values with ":" #342

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Add any styleable component
2. use some full url in the style property like style="background-image:  
http://aaa/aaa.png;"

What is the expected output? 
component should be rendered with the style="background-image:  
http://aaa/aaa.png;"

What do you see instead?
component is rendered width style="background-image:http;"

Please use labels and text to provide additional information.
From class TStyle
at method(line 380) addAttributesToRender it does a $arr=explode(':',$style), 
this makes impossible for any value that uses ":" to be rendered.

Original issue reported on code.google.com by uaca...@gmail.com on 3 Jul 2011 at 11:40

GoogleCodeExporter commented 8 years ago 
i think that replace $arr=explode(':',$style); width 
$arr=explode(':',$style,2); does the trick.
This can be also a performance problem, there is no need to split and glue 
together the style property. If I'm not mistaken there is no way to just add a 
value to be rendered as THtmlWriter needs attribute and value to render. i 
*think* it would be best to teach THtmlWriter to render the $customStyle from 
TStyle without change it, the downside is that now if one set a style using 
PRADOs components like color="blue" it replaces the one in the 
style="color:blue", this would no longer be the case as both values would be 
rendered.

Original comment by uaca...@gmail.com on 3 Jul 2011 at 11:56

GoogleCodeExporter commented 8 years ago 
I say Prado shouldn't really care about that. I mean, without a proper and 
complete inline CSS parser you won't even be able to warn of possible 
duplicates reliable, let alone be able to implement a proper attribute 
management, if you allow styles to be set both through string literals and 
attribute+value pairs. And running everything though a CSS parser would be a 
huge overhead and waste of resources most of the time, since in most cases 
developers obviously don't supply/set redundant sets of attributes on 
components in the first place.

So I'm rather for minimizing style attribute treatment to the minimum possible, 
and let the actual developers sort out their sh.. stuff, in cases where they 
supply contradictory/redundant sets of attributes to Prado or to the renderer.

Original comment by google...@pcforum.hu on 4 Jul 2011 at 1:36

GoogleCodeExporter commented 8 years ago 
Imho while the $arr=explode(':',$style,2); trick is probably the best way to go 
on branch/3.1 to fix the issue while keeping existing code working, while the 
behaviour can be changed in trunk.

Since setCustomStyle() always overwrites the old customstyle with the new one, 
i see no point in splitting $this->_customStyle and handling duplicates in 
THtmlWriter::addStyleAttribute as is done now; additionally, the current 
attribute+value parser is easily tricked by css shorthand properties.

We could just add a THtmlWriter::addStyleString and let TStyle pass to it 
$this->_customStyle (is any).

The user can use the existing specific style properties (eg setBorderColor) or 
the generic StyleField property if he wants to ensure that multiple 
declarations of the same style field won't produce a multiple rendering of that 
css attribute.

Comments?

Original comment by ctrlal...@gmail.com on 6 Jul 2011 at 2:31

GoogleCodeExporter commented 8 years ago 
Applied the $arr=explode(':',$style,2); trick in r3045

Original comment by ctrlal...@gmail.com on 2 Oct 2011 at 9:29

GoogleCodeExporter commented 8 years ago

Original comment by ctrlal...@gmail.com on 25 Jun 2012 at 1:56

GoogleCodeExporter commented 8 years ago

Original comment by ctrlal...@gmail.com on 21 Jan 2013 at 7:03

GoogleCodeExporter commented 8 years ago

Original comment by ctrlal...@gmail.com on 24 Jul 2013 at 1:46

GoogleCodeExporter commented 8 years ago 
Moved to github: https://github.com/pradosoft/prado/issues

Original comment by ctrlal...@gmail.com on 1 Oct 2013 at 10:14