[JBoss JIRA] Commented: (JBIDE-675) Large JSF file are too slow to handle, making editor useless for them
by Snjezana Peco (JIRA)
[ http://jira.jboss.com/jira/browse/JBIDE-675?page=comments#action_12406472 ]
Snjezana Peco commented on JBIDE-675:
-------------------------------------
I haven't said that we can't modify Mozilla DOM using proxy. I have said that calling Mozilla's proxy (UI_THREAD_EVENT_QUEUE) is executing a procedure in the UI thread (the same as using display.asyncExec/display.syncExec).
See this thread: http://dev.eclipse.org/newslists/news.eclipse.platform.swt/msg39748.html
As to the delay (and canceling jobs), it won't help if the user types slowly. It is only a hint if the user types quickly. I took that idea from webtools.
> Large JSF file are too slow to handle, making editor useless for them
> ---------------------------------------------------------------------
>
> Key: JBIDE-675
> URL: http://jira.jboss.com/jira/browse/JBIDE-675
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: JSF, Visual Page Editor
> Affects Versions: ExadelStudioPro4
> Environment: Eclipse 3.2.2
> Exadel Studio 4.0.4
> Kubuntu Feisty Fawn
> 1G RAM
> CPU Intel(R) Pentium(R) 4 CPU 2.80GHz, HyperThreading activated
> Reporter: David Delbecq
> Assigned To: Maxim Areshkau
> Priority: Critical
> Fix For: 2.2.x
>
> Attachments: .classpath, copy_dump.txt, edit_dump1.txt, edit_dump2.txt, editStructure.txt, JBIDE-675.tar.gz, loading_dump.txt, profiling.tar.gz, stacktraces-rhd2b1.log.gz, tree.txt
>
>
> Post to JIRA, following recommandatiopn here: http://jboss.com/index.html?module=bb&op=viewtopic&t=115447
> When editing JSF files That contains quite a lot of include, it take commonly up to 20 seconds for one character i type to get it's way to the screen. I can even see, after 10 seconds, the cursor goes on step right, and after a new 10 second the character appear in front of the cursor. This make it impossible to use JSF editor from exadel to edit such file, i have to ressort to plain xml editor without completion for facelets tags.
> I will be posting attachement containing description of files involved (sorry, no file content).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[JBoss JIRA] Commented: (JBIDE-675) Large JSF file are too slow to handle, making editor useless for them
by Maxim Areshkau (JIRA)
[ http://jira.jboss.com/jira/browse/JBIDE-675?page=comments#action_12406449 ]
Maxim Areshkau commented on JBIDE-675:
--------------------------------------
I have tried display.asyncExec/display.syncExec to use already a third time, for tests I was using employee.xhtml from attachment. I was checked it on eclipse 3.3.1 and eclipse 3.3.2 on Mac OS and Linux, each time user input are suspended.
How Snjezana Peco can arguments why we can't modify Mozilla DOM even using proxy? Can you supply some information except phrase "Mozilla DOM can't be modified in a non-UI thread." Why it can't be modified from non-ui thread? What is different between UI and non-ui thread that we cann't modify mozilla dom?
Why you propose 400ms? I don't think that using delay in this situation take reason. Main problem of edition emplayee.xhtml that some changes can take about 10 seconds to update visual preview on my mashine for one operation, so if user can type smth. and doesn't make interruption mare than 400ms it wiil be work, but if user make some rest in typing for example of 500 ms
the update job will starts and he should wait 10 second to enter a next group of symbols and wait wait again.
> Large JSF file are too slow to handle, making editor useless for them
> ---------------------------------------------------------------------
>
> Key: JBIDE-675
> URL: http://jira.jboss.com/jira/browse/JBIDE-675
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: JSF, Visual Page Editor
> Affects Versions: ExadelStudioPro4
> Environment: Eclipse 3.2.2
> Exadel Studio 4.0.4
> Kubuntu Feisty Fawn
> 1G RAM
> CPU Intel(R) Pentium(R) 4 CPU 2.80GHz, HyperThreading activated
> Reporter: David Delbecq
> Assigned To: Maxim Areshkau
> Priority: Critical
> Fix For: 2.2.x
>
> Attachments: .classpath, copy_dump.txt, edit_dump1.txt, edit_dump2.txt, editStructure.txt, JBIDE-675.tar.gz, loading_dump.txt, profiling.tar.gz, stacktraces-rhd2b1.log.gz, tree.txt
>
>
> Post to JIRA, following recommandatiopn here: http://jboss.com/index.html?module=bb&op=viewtopic&t=115447
> When editing JSF files That contains quite a lot of include, it take commonly up to 20 seconds for one character i type to get it's way to the screen. I can even see, after 10 seconds, the cursor goes on step right, and after a new 10 second the character appear in front of the cursor. This make it impossible to use JSF editor from exadel to edit such file, i have to ressort to plain xml editor without completion for facelets tags.
> I will be posting attachement containing description of files involved (sorry, no file content).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[JBoss JIRA] Updated: (JBIDE-1497) Use single base class for EL parsing
by Max Andersen (JIRA)
[ http://jira.jboss.com/jira/browse/JBIDE-1497?page=all ]
Max Andersen updated JBIDE-1497:
--------------------------------
Fix Version/s: 2.2.x
(was: 2.1)
> Use single base class for EL parsing
> ------------------------------------
>
> Key: JBIDE-1497
> URL: http://jira.jboss.com/jira/browse/JBIDE-1497
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: Cleanup
> Affects Versions: 2.0.0.GA
> Reporter: Alexey Kazakov
> Assigned To: Alexey Kazakov
> Fix For: 2.2.x
>
> Original Estimate: 1 week, 2 days
> Remaining Estimate: 1 week, 2 days
>
> We use different classes to parce EL:
> org.jboss.tools.common.model.util.ELParser (Used by JSF Conten Assist and VPE bundle resolver)
> org.jboss.tools.seam.internal.core.el.SeamELTokenizer (Used by Seam Content Assist and Validator)
> org.jboss.tools.jsf.text.ext.hyperlink.JSPExprHyperlinkPartitioner (Used by JSF Hiperlinks)
> We have to refactor it to use one Basic Parcer for EL and maybe have some implementation for special cases if we need it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[JBoss JIRA] Updated: (JBIDE-1226) Various bugs in visual previews of richfaces components
by Sergey Vasilyev (JIRA)
[ http://jira.jboss.com/jira/browse/JBIDE-1226?page=all ]
Sergey Vasilyev updated JBIDE-1226:
-----------------------------------
Fix Version/s: 2.2.x
(was: 2.1)
May be we will add a dynamic behavior in the next release.
> Various bugs in visual previews of richfaces components
> -------------------------------------------------------
>
> Key: JBIDE-1226
> URL: http://jira.jboss.com/jira/browse/JBIDE-1226
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Visual Page Editor
> Reporter: Gavin King
> Assigned To: Sergey Vasilyev
> Fix For: 2.2.x
>
> Attachments: calendar.png, calendar_ve.png, dataDefinitionList.png, dataDefinitionList_ve.png, dataTable.png, dataTable_ve.png, dropDownMenu.png, dropDownMenu_ve.png, inputNumberSlider.png, inputNumberSlider_ve.png, modalPanel.png, modalPanel_ve.png, panelBar.png, panelBar_ve.png, panelMenu.png, panelMenu_ve.png, status.png, status_ve.png, toolTip.png, toolTip_ve.png, tree.png, tree_ve.png
>
>
> Here's a list of previews that need fixing:
> rich:calendar won't popup, and puts the button in the wrong place
> rich:dataDefinitionList broken
> rich:dropDownMenu nonfunctional
> rich:panelMenu nonfunctional
> rich:panelBar functional, but rendering is broken
> rich:toolTip nonfunctional
> rich:modalPanel nonfunctional
> rich:dataTable broken
> rich:tree sorta works, but the nodes are not functional and don't render as links
> rich:inputNumberSlider and other sliders are ugly
> a4j:status should show some kind of preview
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[JBoss JIRA] Updated: (JBIDE-675) Large JSF file are too slow to handle, making editor useless for them
by Sergey Vasilyev (JIRA)
[ http://jira.jboss.com/jira/browse/JBIDE-675?page=all ]
Sergey Vasilyev updated JBIDE-675:
----------------------------------
Fix Version/s: 2.2.x
(was: 2.1)
To complex bug and we don't have a right way to fix it.
> Large JSF file are too slow to handle, making editor useless for them
> ---------------------------------------------------------------------
>
> Key: JBIDE-675
> URL: http://jira.jboss.com/jira/browse/JBIDE-675
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: JSF, Visual Page Editor
> Affects Versions: ExadelStudioPro4
> Environment: Eclipse 3.2.2
> Exadel Studio 4.0.4
> Kubuntu Feisty Fawn
> 1G RAM
> CPU Intel(R) Pentium(R) 4 CPU 2.80GHz, HyperThreading activated
> Reporter: David Delbecq
> Assigned To: Maxim Areshkau
> Priority: Critical
> Fix For: 2.2.x
>
> Attachments: .classpath, copy_dump.txt, edit_dump1.txt, edit_dump2.txt, editStructure.txt, JBIDE-675.tar.gz, loading_dump.txt, profiling.tar.gz, stacktraces-rhd2b1.log.gz, tree.txt
>
>
> Post to JIRA, following recommandatiopn here: http://jboss.com/index.html?module=bb&op=viewtopic&t=115447
> When editing JSF files That contains quite a lot of include, it take commonly up to 20 seconds for one character i type to get it's way to the screen. I can even see, after 10 seconds, the cursor goes on step right, and after a new 10 second the character appear in front of the cursor. This make it impossible to use JSF editor from exadel to edit such file, i have to ressort to plain xml editor without completion for facelets tags.
> I will be posting attachement containing description of files involved (sorry, no file content).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[JBoss JIRA] Commented: (JBIDE-675) Large JSF file are too slow to handle, making editor useless for them
by Snjezana Peco (JIRA)
[ http://jira.jboss.com/jira/browse/JBIDE-675?page=comments#action_12406272 ]
Snjezana Peco commented on JBIDE-675:
-------------------------------------
Mozilla DOM can't be modified in a non-UI thread. Mozilla's proxy mechanism is just other way to call the UI thread.
You can use Eclipse's display.asyncExec/display.syncExec with the same effect.
I am not sure what you did when you tried to "apply a delay before update", but I proposed the following ( JBIDE-1900 ):
- when a user enters a few chars quickly, the visual part is updated only once (currently, the visual part is updated for every character entered by the user)
The webtools project uses this idea within the sourcevalidation ext. point. I used it for JBIDE-1479 fix. Without the delay, formating of the files included in JBIDE-675.tar.gz is very, very slow (unusable for larger projects).
Within JBIDE-1479 fix, the delay time is set to 1000 ms (see http://jira.jboss.com/jira/browse/JBIDE-1479#action_12394455 ).
Since this delay would probably be too long for source editing, I propose 400ms what is the default value in the webtools project.
It is possible that you added a delay, but didn't cancel any job what slowed down editing.
> Large JSF file are too slow to handle, making editor useless for them
> ---------------------------------------------------------------------
>
> Key: JBIDE-675
> URL: http://jira.jboss.com/jira/browse/JBIDE-675
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: JSF, Visual Page Editor
> Affects Versions: ExadelStudioPro4
> Environment: Eclipse 3.2.2
> Exadel Studio 4.0.4
> Kubuntu Feisty Fawn
> 1G RAM
> CPU Intel(R) Pentium(R) 4 CPU 2.80GHz, HyperThreading activated
> Reporter: David Delbecq
> Assigned To: Maxim Areshkau
> Priority: Critical
> Fix For: 2.1
>
> Attachments: .classpath, copy_dump.txt, edit_dump1.txt, edit_dump2.txt, editStructure.txt, JBIDE-675.tar.gz, loading_dump.txt, profiling.tar.gz, stacktraces-rhd2b1.log.gz, tree.txt
>
>
> Post to JIRA, following recommandatiopn here: http://jboss.com/index.html?module=bb&op=viewtopic&t=115447
> When editing JSF files That contains quite a lot of include, it take commonly up to 20 seconds for one character i type to get it's way to the screen. I can even see, after 10 seconds, the cursor goes on step right, and after a new 10 second the character appear in front of the cursor. This make it impossible to use JSF editor from exadel to edit such file, i have to ressort to plain xml editor without completion for facelets tags.
> I will be posting attachement containing description of files involved (sorry, no file content).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month
[JBoss JIRA] Commented: (JBIDE-1497) Use single base class for EL parsing
by Alexey Kazakov (JIRA)
[ http://jira.jboss.com/jira/browse/JBIDE-1497?page=comments#action_12406264 ]
Alexey Kazakov commented on JBIDE-1497:
---------------------------------------
Lets postpone it. It's not easy to do and we have to test it carefully after fixing.
> Use single base class for EL parsing
> ------------------------------------
>
> Key: JBIDE-1497
> URL: http://jira.jboss.com/jira/browse/JBIDE-1497
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: Cleanup
> Affects Versions: 2.0.0.GA
> Reporter: Alexey Kazakov
> Assigned To: Alexey Kazakov
> Fix For: 2.1
>
> Original Estimate: 1 week, 2 days
> Remaining Estimate: 1 week, 2 days
>
> We use different classes to parce EL:
> org.jboss.tools.common.model.util.ELParser (Used by JSF Conten Assist and VPE bundle resolver)
> org.jboss.tools.seam.internal.core.el.SeamELTokenizer (Used by Seam Content Assist and Validator)
> org.jboss.tools.jsf.text.ext.hyperlink.JSPExprHyperlinkPartitioner (Used by JSF Hiperlinks)
> We have to refactor it to use one Basic Parcer for EL and maybe have some implementation for special cases if we need it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month