[jira] Created: (TAP5-1280) Resolve page templates-like-this to classes with the name TemplatesLikeThis
Resolve page templates-like-this to classes with the name TemplatesLikeThis --- Key: TAP5-1280 URL: https://issues.apache.org/jira/browse/TAP5-1280 Project: Tapestry 5 Issue Type: New Feature Components: tapestry-core Affects Versions: 5.1.0.5 Reporter: Toby Would be nice, if the default behavour of Tapestry5 would map URLs separated by dash similiar to URLs without dashes. Example: /keyword-rich-url Page: keyword-rich-url.tml Java class: KeywordRichURL Of course, anyone could do this by URLEncoders/Decoders - the more out-of-the-box features Tapestry5 offers, the better though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1280) Resolve page templates-like-this to classes with the name TemplatesLikeThis
[ https://issues.apache.org/jira/browse/TAP5-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toby updated TAP5-1280: --- Priority: Minor (was: Major) > Resolve page templates-like-this to classes with the name TemplatesLikeThis > --- > > Key: TAP5-1280 > URL: https://issues.apache.org/jira/browse/TAP5-1280 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core >Affects Versions: 5.1.0.5 >Reporter: Toby >Priority: Minor > > Would be nice, if the default behavour of Tapestry5 would map URLs separated > by dash similiar to URLs without dashes. > Example: > /keyword-rich-url > Page: keyword-rich-url.tml > Java class: KeywordRichURL > Of course, anyone could do this by URLEncoders/Decoders - the more > out-of-the-box features Tapestry5 offers, the better though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1279) The stack model for JavaScript combination doesn't de-duplicate individual references
[ https://issues.apache.org/jira/browse/TAP5-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912886#action_12912886 ] Andy Blower commented on TAP5-1279: --- Follow up to TAP5-769 > The stack model for JavaScript combination doesn't de-duplicate individual > references > - > > Key: TAP5-1279 > URL: https://issues.apache.org/jira/browse/TAP5-1279 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core >Affects Versions: 5.2.0, 5.2.1 >Reporter: Andy Blower > > The stack mechanism doesn't seem to be removing duplicate javascript > references as I expect it to. Tapestry JS has always worked on a component > requesting the JS assets it needs and then Tapestry ensured that each > required JS asset was added to the page once and only once, even if several > components asked for the same JS asset. The stack system doesn't seem to > follow this model... > For example, say I have a component "Comp" that specifies it needs the > "CompJS" asset, and is used on pages "Page1" and "Page2". If Page1 doesn't > have much more to it and only needs CompJS then that's what should be > included by Tapestry, since Comp @Import's CompJS. All well and good. > Now, if Page2 has a lot of other components with their own JS files which are > then combined into a T5 stack and requested by the page's @Import then I > would not expect CompJS to be referenced on the page since it's already > included in the stack file. It seems to be in T5.2.0 with my testing. > Unless I'm mistaken about how this is working, then I fail to see how this > stack mechanism provides much benefit over simply putting all my projects' JS > into a single file and referencing that in each page. The only advantage is > to split it up into easily editable chunks, I still have to manage the > aggregation. I think it's going to be very easy to get duplicate JS in the > rendered html page with this system. > If a stack is imported which contains CompJS, and another component imports > CompJS individually, just output the reference to the stack, and not CompJS. > There are two ways to implement the remaining behaviour: > 1) If the stack is not imported, and a component imports CompJS individually, > just output the reference to CompJS. > 2) If the stack is not imported, and a component imports CompJS individually, > output a reference to the stack containing CompJS. This is more difficult and > may be tricky if the component has been defined as being part of more than > one stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-1279) The stack model for JavaScript combination doesn't de-duplicate individual references
The stack model for JavaScript combination doesn't de-duplicate individual references - Key: TAP5-1279 URL: https://issues.apache.org/jira/browse/TAP5-1279 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.2.0, 5.2.1 Reporter: Andy Blower The stack mechanism doesn't seem to be removing duplicate javascript references as I expect it to. Tapestry JS has always worked on a component requesting the JS assets it needs and then Tapestry ensured that each required JS asset was added to the page once and only once, even if several components asked for the same JS asset. The stack system doesn't seem to follow this model... For example, say I have a component "Comp" that specifies it needs the "CompJS" asset, and is used on pages "Page1" and "Page2". If Page1 doesn't have much more to it and only needs CompJS then that's what should be included by Tapestry, since Comp @Import's CompJS. All well and good. Now, if Page2 has a lot of other components with their own JS files which are then combined into a T5 stack and requested by the page's @Import then I would not expect CompJS to be referenced on the page since it's already included in the stack file. It seems to be in T5.2.0 with my testing. Unless I'm mistaken about how this is working, then I fail to see how this stack mechanism provides much benefit over simply putting all my projects' JS into a single file and referencing that in each page. The only advantage is to split it up into easily editable chunks, I still have to manage the aggregation. I think it's going to be very easy to get duplicate JS in the rendered html page with this system. If a stack is imported which contains CompJS, and another component imports CompJS individually, just output the reference to the stack, and not CompJS. There are two ways to implement the remaining behaviour: 1) If the stack is not imported, and a component imports CompJS individually, just output the reference to CompJS. 2) If the stack is not imported, and a component imports CompJS individually, output a reference to the stack containing CompJS. This is more difficult and may be tricky if the component has been defined as being part of more than one stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
