[ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin... ] Vitali Yemialyanchyk updated JBIDE-9372: ---------------------------------------- Description: rather big pages - in general dev project this is normal page size... My proposition for VPE developers pay attention to performance. This is example place to enhancement: VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this: ElService.getInstance().replaceElAndResources(this.pageContext, toReplace); ElService -> replaceEl -> getAllResources - array creation (!) and then ElService -> replaceEl -> replace - clone array (!) and then array sort (!) FOR EVERY sourceNode.getAttribute("...") in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...} array create and sort operations should be performed only one time! moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly. was: rather big pages - in general dev project this is normal page size... My proposition for VPE developers pay attention to performance. This is example place to enhancement: VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this: ElService.getInstance().replaceElAndResources(this.pageContext, toReplace); ElService -> replaceEl -> getAllResources - array creation and then ElService -> replaceEl -> replace - array sort FOR EVERY sourceNode.getAttribute("...") in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...} array create and sort operations should be performed only one time! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin... ] Vitali Yemialyanchyk updated JBIDE-9372: ---------------------------------------- Description: rather big pages - in general dev project this is normal page size... My proposition for VPE developers pay attention to performance. This is example place to enhancement: VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this: ElService.getInstance().replaceElAndResources(this.pageContext, toReplace); ElService -> replaceEl -> getAllResources - array creation (!) and then ElService -> replaceEl -> replace - clone array (!) and then array sort (!) FOR EVERY sourceNode.getAttribute("...") in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...} array create and sort operations should be performed only one time! moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly. the same for function ElService -> replaceCustomAttributes Jsf2ResourceUtil.processExternalContextPath & Jsf2ResourceUtil.processRequestContextPath - it is possible to optimize both of these functions... Example how should be: public static String processRequestContextPath(String value) { return jsfRequestContextPath.matcher(value).replaceFirst(""); } and task for developers - find arguments - why it has mach-mach better performance if we call this function several 1000 of times... other detail which I admit in ElService -> replaceElAndResources - why you guy do not use intermediate variables? your code snippet: if((pageContext.getVisualBuilder().getCurrentIncludeInfo()==null) || !(pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile) pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage(); my code snippet: final VpeIncludeInfo vii = pageContext.getVisualBuilder().getCurrentIncludeInfo(); if (vii == null || !(vii.getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile)vii.getStorage(); I advise and recommend use intermediate variables! You will reduce functions call (in my example only 1 time instead of 3), you will reduce code, you make code more readable. was: rather big pages - in general dev project this is normal page size... My proposition for VPE developers pay attention to performance. This is example place to enhancement: VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this: ElService.getInstance().replaceElAndResources(this.pageContext, toReplace); ElService -> replaceEl -> getAllResources - array creation (!) and then ElService -> replaceEl -> replace - clone array (!) and then array sort (!) FOR EVERY sourceNode.getAttribute("...") in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...} array create and sort operations should be performed only one time! moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly. the same for function ElService -> replaceCustomAttributes Jsf2ResourceUtil.processExternalContextPath & Jsf2ResourceUtil.processRequestContextPath - it is possible to optimize both of these functions... Example how should be: public static String processRequestContextPath(String value) { return jsfRequestContextPath.matcher(value).replaceFirst(""); } and task for developers - find arguments - why it has mach-mach better performance if we call this function several 1000 of times... other detail which I admit in ElService -> replaceElAndResources - why you guy do not use intermediate variables? your code snippet: if((pageContext.getVisualBuilder().getCurrentIncludeInfo()==null) || !(pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile) pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage(); my code snippet: final VpeIncludeInfo vii = pageContext.getVisualBuilder().getCurrentIncludeInfo(); if (vii == null || !(vii.getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile)vii.getStorage(); I advise and recommend use intermediate variables! You will reduce functions call (in my example only 1 time instead of 3), you will reduce code, you make code more readable. > VPE has a serious performance drawback for rather big pages > ----------------------------------------------------------- > > Key: JBIDE-9372 > URL: https://issues.jboss.org/browse/JBIDE-9372 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: Visual Page Editor core, Visual Page Editor Templates > Affects Versions: 3.3.0.M3 > Reporter: Vitali Yemialyanchyk > Assignee: Yahor Radtsevich > Priority: Minor > Fix For: 3.3.0.M3 > > > rather big pages - in general dev project this is normal page size... > My proposition for VPE developers pay attention to performance. This is example place to enhancement: > VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this: > ElService.getInstance().replaceElAndResources(this.pageContext, toReplace); > ElService -> replaceEl -> getAllResources - array creation (!) and then > ElService -> replaceEl -> replace - clone array (!) and then array sort (!) > FOR EVERY sourceNode.getAttribute("...") > in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...} > array create and sort operations should be performed only one time! > moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle > here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly. > the same for function ElService -> replaceCustomAttributes > Jsf2ResourceUtil.processExternalContextPath & Jsf2ResourceUtil.processRequestContextPath - it is possible to optimize both of these functions... Example how should be: > public static String processRequestContextPath(String value) { > return jsfRequestContextPath.matcher(value).replaceFirst(""); > } > and task for developers - find arguments - why it has mach-mach better performance if we call this function several 1000 of times... > other detail which I admit in ElService -> replaceElAndResources - why you guy do not use intermediate variables? > your code snippet: > > if((pageContext.getVisualBuilder().getCurrentIncludeInfo()==null) > || !(pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage() instanceof IFile)) { > return rst; > } > final IFile file = (IFile) pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage(); > > my code snippet: > > final VpeIncludeInfo vii = pageContext.getVisualBuilder().getCurrentIncludeInfo(); > if (vii == null || !(vii.getStorage() instanceof IFile)) { > return rst; > } > final IFile file = (IFile)vii.getStorage(); > > I advise and recommend use intermediate variables! You will reduce functions call (in my example only 1 time instead of 3), you will reduce code, you make code more readable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin... ] Vitali Yemialyanchyk updated JBIDE-9372: ---------------------------------------- Description: rather big pages - in general dev project this is normal page size... My proposition for VPE developers pay attention to performance. This is example place to enhancement: VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this: ElService.getInstance().replaceElAndResources(this.pageContext, toReplace); ElService -> replaceEl -> getAllResources - array creation (!) and then ElService -> replaceEl -> replace - clone array (!) and then array sort (!) FOR EVERY sourceNode.getAttribute("...") in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...} array create and sort operations should be performed only one time! moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly. the same for function ElService -> replaceCustomAttributes Jsf2ResourceUtil.processExternalContextPath & Jsf2ResourceUtil.processRequestContextPath - it is possible to optimize both of these functions... Example how should be: public static String processRequestContextPath(String value) { return jsfRequestContextPath.matcher(value).replaceFirst(""); } and task for developers - find arguments - why it has mach-mach better performance if we call this function several 1000 of times... other detail which I admit in ElService -> replaceElAndResources - why you guy do not use intermediate variables? your code snippet: if((pageContext.getVisualBuilder().getCurrentIncludeInfo()==null) || !(pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile) pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage(); my code snippet: final VpeIncludeInfo vii = pageContext.getVisualBuilder().getCurrentIncludeInfo(); if (vii == null || !(vii.getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile)vii.getStorage(); I advise and recommend use intermediate variables! You will reduce functions call (in my example only 1 time instead of 3), you will reduce code, you make code more readable. - the same for ElService -> isELNode was: rather big pages - in general dev project this is normal page size... My proposition for VPE developers pay attention to performance. This is example place to enhancement: VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this: ElService.getInstance().replaceElAndResources(this.pageContext, toReplace); ElService -> replaceEl -> getAllResources - array creation (!) and then ElService -> replaceEl -> replace - clone array (!) and then array sort (!) FOR EVERY sourceNode.getAttribute("...") in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...} array create and sort operations should be performed only one time! moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly. the same for function ElService -> replaceCustomAttributes Jsf2ResourceUtil.processExternalContextPath & Jsf2ResourceUtil.processRequestContextPath - it is possible to optimize both of these functions... Example how should be: public static String processRequestContextPath(String value) { return jsfRequestContextPath.matcher(value).replaceFirst(""); } and task for developers - find arguments - why it has mach-mach better performance if we call this function several 1000 of times... other detail which I admit in ElService -> replaceElAndResources - why you guy do not use intermediate variables? your code snippet: if((pageContext.getVisualBuilder().getCurrentIncludeInfo()==null) || !(pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile) pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage(); my code snippet: final VpeIncludeInfo vii = pageContext.getVisualBuilder().getCurrentIncludeInfo(); if (vii == null || !(vii.getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile)vii.getStorage(); I advise and recommend use intermediate variables! You will reduce functions call (in my example only 1 time instead of 3), you will reduce code, you make code more readable. > VPE has a serious performance drawback for rather big pages > ----------------------------------------------------------- > > Key: JBIDE-9372 > URL: https://issues.jboss.org/browse/JBIDE-9372 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: Visual Page Editor core, Visual Page Editor Templates > Affects Versions: 3.3.0.M3 > Reporter: Vitali Yemialyanchyk > Assignee: Yahor Radtsevich > Priority: Minor > Fix For: 3.3.0.M3 > > > rather big pages - in general dev project this is normal page size... > My proposition for VPE developers pay attention to performance. This is example place to enhancement: > VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this: > ElService.getInstance().replaceElAndResources(this.pageContext, toReplace); > ElService -> replaceEl -> getAllResources - array creation (!) and then > ElService -> replaceEl -> replace - clone array (!) and then array sort (!) > FOR EVERY sourceNode.getAttribute("...") > in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...} > array create and sort operations should be performed only one time! > moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle > here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly. > the same for function ElService -> replaceCustomAttributes > Jsf2ResourceUtil.processExternalContextPath & Jsf2ResourceUtil.processRequestContextPath - it is possible to optimize both of these functions... Example how should be: > public static String processRequestContextPath(String value) { > return jsfRequestContextPath.matcher(value).replaceFirst(""); > } > and task for developers - find arguments - why it has mach-mach better performance if we call this function several 1000 of times... > other detail which I admit in ElService -> replaceElAndResources - why you guy do not use intermediate variables? > your code snippet: > > if((pageContext.getVisualBuilder().getCurrentIncludeInfo()==null) || !(pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage() instanceof IFile)) { > return rst; > } > final IFile file = (IFile) pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage(); > > my code snippet: > > final VpeIncludeInfo vii = pageContext.getVisualBuilder().getCurrentIncludeInfo(); > if (vii == null || !(vii.getStorage() instanceof IFile)) { > return rst; > } > final IFile file = (IFile)vii.getStorage(); > > I advise and recommend use intermediate variables! You will reduce functions call (in my example only 1 time instead of 3), you will reduce code, you make code more readable. > - the same for ElService -> isELNode -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin... ] Vitali Yemialyanchyk commented on JBIDE-9372: --------------------------------------------- Yahor, one more thing... It would be nice if you will use one code style for all over the code - Eclipse build-in code style is a good thing - only possible to use more long lines, for example 120 symbols. Of course one code style does not allow to developers express his individuality, but it allows others easy read code... I do not know is your components dev. politics allows this - reformat all VPE code at once - or your prefer express your individuality... As I think VPE community ask for "reformat" decision. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin... ] Yahor Radtsevich commented on JBIDE-9372: ----------------------------------------- Yeah, one code style would be a good thing. But I prefer to leave everything as is by two reasons: # It is easier to see who, when and why committed a particular line of code (i.e. to use svn annotate) # Automatic formatting is not the best option, because it often makes code less readable -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin... ] Vitali Yemialyanchyk updated JBIDE-9372: ---------------------------------------- Description: rather big pages - in general dev project this is normal page size... My proposition for VPE developers pay attention to performance. This is example place to enhancement: VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this: ElService.getInstance().replaceElAndResources(this.pageContext, toReplace); ElService -> replaceEl -> getAllResources - array creation (!) and then ElService -> replaceEl -> replace - clone array (!) and then array sort (!) FOR EVERY sourceNode.getAttribute("...") in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...} array create and sort operations should be performed only one time! moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly. the same for function ElService -> replaceCustomAttributes Jsf2ResourceUtil.processExternalContextPath & Jsf2ResourceUtil.processRequestContextPath - it is possible to optimize both of these functions... Example how should be: public static String processRequestContextPath(String value) { return jsfRequestContextPath.matcher(value).replaceFirst(""); } and task for developers - find arguments - why it has mach-mach better performance if we call this function several 1000 of times... other detail which I admit in ElService -> replaceElAndResources - why you guy do not use intermediate variables? your code snippet: if((pageContext.getVisualBuilder().getCurrentIncludeInfo()==null) || !(pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile) pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage(); my code snippet: final VpeIncludeInfo vii = pageContext.getVisualBuilder().getCurrentIncludeInfo(); if (vii == null || !(vii.getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile)vii.getStorage(); I advise and recommend use intermediate variables! You will reduce functions call (in my example only 1 time instead of 3), you will reduce code, you make code more readable. - the same for ElService -> isELNode one more advice to avoid performance problems is move all calculations which is possible out of the cycle: take a look VpeStyleUtil -> "public static String addFullPathIntoURLValue(String value, VpePageContext pageContext)" -> here you extract getStorage - for every cycle iteration - for such cases I recommend do this only once - before the cycle. was: rather big pages - in general dev project this is normal page size... My proposition for VPE developers pay attention to performance. This is example place to enhancement: VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this: ElService.getInstance().replaceElAndResources(this.pageContext, toReplace); ElService -> replaceEl -> getAllResources - array creation (!) and then ElService -> replaceEl -> replace - clone array (!) and then array sort (!) FOR EVERY sourceNode.getAttribute("...") in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...} array create and sort operations should be performed only one time! moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly. the same for function ElService -> replaceCustomAttributes Jsf2ResourceUtil.processExternalContextPath & Jsf2ResourceUtil.processRequestContextPath - it is possible to optimize both of these functions... Example how should be: public static String processRequestContextPath(String value) { return jsfRequestContextPath.matcher(value).replaceFirst(""); } and task for developers - find arguments - why it has mach-mach better performance if we call this function several 1000 of times... other detail which I admit in ElService -> replaceElAndResources - why you guy do not use intermediate variables? your code snippet: if((pageContext.getVisualBuilder().getCurrentIncludeInfo()==null) || !(pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile) pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage(); my code snippet: final VpeIncludeInfo vii = pageContext.getVisualBuilder().getCurrentIncludeInfo(); if (vii == null || !(vii.getStorage() instanceof IFile)) { return rst; } final IFile file = (IFile)vii.getStorage(); I advise and recommend use intermediate variables! You will reduce functions call (in my example only 1 time instead of 3), you will reduce code, you make code more readable. - the same for ElService -> isELNode > VPE has a serious performance drawback for rather big pages > ----------------------------------------------------------- > > Key: JBIDE-9372 > URL: https://issues.jboss.org/browse/JBIDE-9372 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: Visual Page Editor core, Visual Page Editor Templates > Affects Versions: 3.3.0.M3 > Reporter: Vitali Yemialyanchyk > Assignee: Yahor Radtsevich > Priority: Minor > Fix For: 3.3.0.M3 > > > rather big pages - in general dev project this is normal page size... > My proposition for VPE developers pay attention to performance. This is example place to enhancement: > VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this: > ElService.getInstance().replaceElAndResources(this.pageContext, toReplace); > ElService -> replaceEl -> getAllResources - array creation (!) and then > ElService -> replaceEl -> replace - clone array (!) and then array sort (!) > FOR EVERY sourceNode.getAttribute("...") > in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...} > array create and sort operations should be performed only one time! > moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle > here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly. > the same for function ElService -> replaceCustomAttributes > Jsf2ResourceUtil.processExternalContextPath & Jsf2ResourceUtil.processRequestContextPath - it is possible to optimize both of these functions... Example how should be: > public static String processRequestContextPath(String value) { > return jsfRequestContextPath.matcher(value).replaceFirst(""); > } > and task for developers - find arguments - why it has mach-mach better performance if we call this function several 1000 of times... > other detail which I admit in ElService -> replaceElAndResources - why you guy do not use intermediate variables? > your code snippet: > > if((pageContext.getVisualBuilder().getCurrentIncludeInfo()==null) || !(pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage() instanceof IFile)) { > return rst; > } > final IFile file = (IFile) pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage(); > > my code snippet: > > final VpeIncludeInfo vii = pageContext.getVisualBuilder().getCurrentIncludeInfo(); > if (vii == null || !(vii.getStorage() instanceof IFile)) { > return rst; > } > final IFile file = (IFile)vii.getStorage(); > > I advise and recommend use intermediate variables! You will reduce functions call (in my example only 1 time instead of 3), you will reduce code, you make code more readable. > - the same for ElService -> isELNode > one more advice to avoid performance problems is move all calculations which is possible out of the cycle: > take a look VpeStyleUtil -> "public static String addFullPathIntoURLValue(String value, VpePageContext pageContext)" -> > here you extract getStorage - for every cycle iteration - for such cases I recommend do this only once - before the cycle. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin... ] Yahor Radtsevich commented on JBIDE-9372: ----------------------------------------- Any patches that can fix this situation are always welcome! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin... ] Vitali Yemialyanchyk commented on JBIDE-9372: --------------------------------------------- sorry I can not preserve code formatting for several classes cause I change much in where... all logic is the same - just changes which I describe above - I've check -> all VPE testes pass correctly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin... ] Vitali Yemialyanchyk updated JBIDE-9372: ---------------------------------------- Attachment: JBIDE-9372_20110722_2.patch JBIDE-9372_20110722_2.patch - is a right version; JBIDE-9372_20110722.patch - has a typo. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin... ] Yahor Radtsevich resolved JBIDE-9372. ------------------------------------- Resolution: Done *Resolved* The patch is applied with very minor changes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin... ] Vitali Yemialyanchyk closed JBIDE-9372. --------------------------------------- closed -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira