[jira] Updated: (TAP5-1048) Support for IE conditional stylesheets will need changes to DocumentLinkerImpl

2010-03-10 Thread Andy Blower (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Blower updated TAP5-1048:
--

Attachment: TAP5-1048-patch.txt

This does fix the problem, but it's not the most satisfactory solution. Without 
changing the Node/Raw/Element classes I couldn't see another way to fix it.

 Support for IE conditional stylesheets will need changes to DocumentLinkerImpl
 --

 Key: TAP5-1048
 URL: https://issues.apache.org/jira/browse/TAP5-1048
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Andy Blower
Priority: Minor
 Attachments: TAP5-1048-patch.txt


 I'm having the issue described in TAP5-56, and although it's fairly easily 
 solved using a component (see: http://markmail.org/message/aidg4w223t5yaass) 
 or some other way, this is still not sufficient. The problem is in the 
 ordering of the stylesheets in the final rendered HTML output. The 
 addStylesheetsToHead() method of DocumentLinkerImpl adds the included 
 stylesheets and then moves them before any stylesheet links already in the 
 dom. This fails if one of the existing stylesheet links is a conditional one, 
 as findExistingElement() doesn't find the comment.
 I've tried modifying the service, but because comments are Raw node, it's 
 difficult to put a bunch of Element nodes before one in the DOM. The only way 
 I could think of is included as a patch - findExistingElement() can return 
 the previous Element which can then have the link element nodes placed after 
 rather than before. This works, but is not very satisfactory.
 I can't use this anyway because overriding that T5 DocumentLinkerImpl is 
 fragile and breaks in some of our environments. I spent several hours 
 aliasing and overriding this 'service' before I realised that DocumentLinker 
 is not actually a service! It's in the internal.services package, but isn't 
 actually a service - it's instantiated directly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (TAP5-1048) Support for IE conditional stylesheets will need changes to DocumentLinkerImpl

2010-03-10 Thread Andy Blower (JIRA)

 [ 
https://issues.apache.org/jira/browse/TAP5-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Blower updated TAP5-1048:
--

Description: 
I'm having the issue described in TAP5-56, and although it's fairly easily 
solved using a component (see: http://markmail.org/message/aidg4w223t5yaass) or 
some other way, this is still not sufficient. The problem is in the ordering of 
the stylesheets in the final rendered HTML output. The addStylesheetsToHead() 
method of DocumentLinkerImpl adds the included stylesheets and then moves them 
before any stylesheet links already in the dom. This fails if one of the 
existing stylesheet links is a conditional one, as findExistingElement() 
doesn't find the comment.

I've tried modifying the service, but because comments are Raw node, it's 
difficult to put a bunch of Element nodes before one in the DOM. The only way I 
could think of is included as a patch - findExistingElement() can return the 
previous Element which can then have the link element nodes placed after rather 
than before. This works, but is not very satisfactory.

I can't use this anyway because overriding that T5 DocumentLinkerImpl is 
fragile and breaks in some of our environments. I spent several hours aliasing 
and overriding this 'service' before I realised that DocumentLinker is not 
actually a service! It's in the internal.services package, but isn't actually a 
service - it's instantiated directly.

  was:
I'm having the issue described in TAP5-56, and although it's fairly easily 
solved using a component (see: http://markmail.org/message/aidg4w223t5yaass) or 
some other way, this is still not sufficient. The problem is in the ordering of 
the stylesheets in the final rendered HTML output. The addStylesheetsToHead() 
method of DocumentLinkerImpl adds the included stylesheets and then moves them 
before any stylesheet links already in the dom. This fails if one of the 
existing stylesheet links is a conditional one, as findExistingElement() 
doesn't find the comment.

I've tried modifying the service, but because comments are Raw node, it seems 
impossible to put a bunch of Element nodes before one in the DOM.


 Support for IE conditional stylesheets will need changes to DocumentLinkerImpl
 --

 Key: TAP5-1048
 URL: https://issues.apache.org/jira/browse/TAP5-1048
 Project: Tapestry 5
  Issue Type: Bug
  Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Andy Blower
Priority: Minor
 Attachments: TAP5-1048-patch.txt


 I'm having the issue described in TAP5-56, and although it's fairly easily 
 solved using a component (see: http://markmail.org/message/aidg4w223t5yaass) 
 or some other way, this is still not sufficient. The problem is in the 
 ordering of the stylesheets in the final rendered HTML output. The 
 addStylesheetsToHead() method of DocumentLinkerImpl adds the included 
 stylesheets and then moves them before any stylesheet links already in the 
 dom. This fails if one of the existing stylesheet links is a conditional one, 
 as findExistingElement() doesn't find the comment.
 I've tried modifying the service, but because comments are Raw node, it's 
 difficult to put a bunch of Element nodes before one in the DOM. The only way 
 I could think of is included as a patch - findExistingElement() can return 
 the previous Element which can then have the link element nodes placed after 
 rather than before. This works, but is not very satisfactory.
 I can't use this anyway because overriding that T5 DocumentLinkerImpl is 
 fragile and breaks in some of our environments. I spent several hours 
 aliasing and overriding this 'service' before I realised that DocumentLinker 
 is not actually a service! It's in the internal.services package, but isn't 
 actually a service - it's instantiated directly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.