Re: Missing an answer to a simple question in the forum
by akazakov＠exadel.com
>>> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112651#4112651
>>> Anyone that could help out ? It should just work shouldn't it ?
>>
>> Max, I've answered on forum.
>
> thanks.
>
>> There is Content Assist of WTP in JSP editor for tag names. And it needs
>> TLDs. Our CA is used only for attribute values.
>> In XHTML (for facelets) we use our CA (based on our knowledgebase) for
>> tags, attributes and values. So TLDs are not used.
>
> ok.
>
>>> btw. do we actually parse unknown TLD's dynamically or do we 100% rely
>>> on
>>> having
>>> the knowledgebase uptodate with the corresponding TLD's ?
>>
>> We parse unknown TLD only when user drops some tag from Palette.
>
> And do they then come available in code assist ?
Yes.
>
>> If user wants to have CA for unknown tag lib within facelet page then he
>> should import TLD into Palette and DnD any tag to xhtml. In that moment
>> we
>> try to find TLD then parse it and register it in our knowledgebase. We
>> need it to open our window where user can set attributes values during
>> DnD.
>
>> But after that our CA is able to use parsed TLD as well. Such TLDs
>> are specials for our KB plugin and we check any changes of it. If user
>> chenged it then we reparse it.
>> Preinstalled TLD (like JSF core, Richfaces, ...) are static for our KB.
>> But as I mentioned it could be problem for facelet pages only.
>
>
>> For JSP WTP uses real TLDs from projects.
>
> so why don't we do like they do for JSP WTP and parse TLD's when the user
> refer to them in facelets instead
> of waiting for the drag to the palette?
>
We created our content assist for jsp files much before the first version
of WTP. It's pretty simple but it was working much better then WTP's one
for long time. Now we don't need to refactor our CA for JSP because WTP
works fine now and we almost don't use our one.
But we use our CA for facelets pages. And we can not use WTP's approach
for that case. Facelets don't use TLDs and tag libs xmls don't contain any
information about attributes.
Let's plan some time for this work for future versions.
>
> /max
>
>>>
>>> --
>>> --
>>> Max Rydahl Andersen
>>> callto://max.rydahl.andersen
>>>
>>> Hibernate
>>> max(a)hibernate.org
>>> http://hibernate.org
>>>
>>> JBoss a division of Red Hat
>>> max.andersen(a)jboss.com
>>>
>>>
>>
>
>
>
> --
> --
> Max Rydahl Andersen
> callto://max.rydahl.andersen
>
> Hibernate
> max(a)hibernate.org
> http://hibernate.org
>
> JBoss a division of Red Hat
> max.andersen(a)jboss.com
>
18 years, 10 months
Re: Missing an answer to a simple question in the forum
by akazakov＠exadel.com
> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112651#4112651
> Anyone that could help out ? It should just work shouldn't it ?
Max, I've answered on forum.
There is Content Assist of WTP in JSP editor for tag names. And it needs
TLDs. Our CA is used only for attribute values.
In XHTML (for facelets) we use our CA (based on our knowledgebase) for
tags, attributes and values. So TLDs are not used.
> btw. do we actually parse unknown TLD's dynamically or do we 100% rely on
> having
> the knowledgebase uptodate with the corresponding TLD's ?
We parse unknown TLD only when user drops some tag from Palette.
If user wants to have CA for unknown tag lib within facelet page then he
should import TLD into Palette and DnD any tag to xhtml. In that moment we
try to find TLD then parse it and register it in our knowledgebase. We
need it to open our window where user can set attributes values during
DnD. But after that our CA is able to use parsed TLD as well. Such TLDs
are specials for our KB plugin and we check any changes of it. If user
chenged it then we reparse it.
Preinstalled TLD (like JSF core, Richfaces, ...) are static for our KB.
But as I mentioned it could be problem for facelet pages only. For JSP WTP
uses real TLDs from projects.
>
> --
> --
> Max Rydahl Andersen
> callto://max.rydahl.andersen
>
> Hibernate
> max(a)hibernate.org
> http://hibernate.org
>
> JBoss a division of Red Hat
> max.andersen(a)jboss.com
>
>
18 years, 10 months
Re: Fwd: [jbosstools-commits] JBoss Tools SVN: r5304 - trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam.
by Max Rydahl Andersen
cc'ing in tools dev again ;)
> Max, I get rid from useless antlr jars (antlr-runtime.jar &
> ant-antlr.jar)
> from org.jboss.tools.jsf.vpe.seam plugin (I put that here cause as I
> think
> it could be usefull to have all necessary jars in one place - and don't
> look for it in the case of necessity).
Ok - any idea why antlr-runtime.jar is not enough ?
> Code snippets in org.jboss.seam.text and in org.jboss.seam.test.unit are
> exact copy. org.jboss.seam.text - fully antlr generated code.
> org.jboss.seam.test.unit - small piece with text and main function to see
> how the parser work. I don't sure - should I create new test plugin for
> only
> SeamTextTest.java? or I should just delete the SeamTextTest?
If it is test code it should be in the test plugin (afaik there already
exist a test plugin for this...if not there should)
But more importantly, these are LGPL code and are not marked clearly as
such. They should
and please put it in a .xpl package as been done with the rest of the
non-EPL code.
> Antlr.jar - is useful we should use it for full functionality of
> s:formattedText support - in other case it'll be too complex.
Yes, understood.
/max
> -----Original Message-----
> From: external-exadel-list-bounces(a)redhat.com
> [mailto:external-exadel-list-bounces@redhat.com] On Behalf Of Max Rydahl
> Andersen
> Sent: Monday, December 17, 2007 9:48 AM
> To: Max Rydahl Andersen; jbosstools-dev(a)lists.jboss.org
> Cc: external-exadel-list(a)redhat.com
> Subject: Re: Fwd: [jbosstools-commits] JBoss Tools SVN: r5304 -
> trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam.
>
>> why are we adding new features and "largish" new antlr dependencies in
>> 2.0.1 !?
>
> Is vyemialyanchyk on the dev-list ?
>
> I found that we now blindly included lgpl code from JBoss Seam into our
> plugins without any
> notice on the files. We need to fix that! (LGPL should be marked clearly
> as such and where it comes from and put in .xpl package)
>
> Furthermore it seems like there are test code mixed in with the main code
> - need to fix that too (this should
> be in the test plugins)
>
> And I still fail to understand what ant-antlr.jar and antlr.jar is doing
> on the runtime classpath of our plugins.
> antlr-runtime.jar I understand since the parser is dependent on it, but
> again why is this being added to 2.0.1 and
> is this ok at runtime considering that antlr is to be found in other
> plugins too (hibernate for one) !?
>
> /max
>
>> -max
>>
>> ------- Forwarded message -------
>> From: jbosstools-commits(a)lists.jboss.org
>> To: jbosstools-commits(a)lists.jboss.org
>> Cc:
>> Subject: [jbosstools-commits] JBoss Tools SVN: r5304 -
>> trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam.
>> Date: Fri, 14 Dec 2007 13:40:11 +0100
>>
>> Author: vyemialyanchyk
>> Date: 2007-12-14 07:40:10 -0500 (Fri, 14 Dec 2007)
>> New Revision: 5304
>>
>> Modified:
>> trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/.classpath
>> trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/build.properties
>> Log:
>> http://jira.jboss.com/jira/browse/JBIDE-1449
>>
>> Modified: trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/.classpath
>> ===================================================================
>> --- trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/.classpath 2007-12-14
>> 12:39:40 UTC (rev 5303)
>> +++ trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/.classpath 2007-12-14
>> 12:40:10 UTC (rev 5304)
>> @@ -3,5 +3,8 @@
>> <classpathentry kind="src" path="src"/>
>> <classpathentry kind="con"
>> path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
>> <classpathentry kind="con"
>> path="org.eclipse.pde.core.requiredPlugins"/>
>> + <classpathentry kind="lib" path="lib/ant-antlr.jar"/>
>> + <classpathentry kind="lib" path="lib/antlr.jar"/>
>> + <classpathentry kind="lib" path="lib/antlr-runtime.jar"/>
>> <classpathentry kind="output" path="bin"/>
>> </classpath>
>>
>> Modified:
>> trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/build.properties
>> ===================================================================
>> ---
>> trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/build.properties
> 2007-12-14
>> 12:39:40 UTC (rev 5303)
>> +++
>> trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/build.properties
> 2007-12-14
>> 12:40:10 UTC (rev 5304)
>> @@ -3,11 +3,10 @@
>> bin.includes = META-INF/,\
>> .,\
>> plugin.xml,\
>> + lib/,\
>> + lib/ant-antlr.jar,\
>> + lib/antlr.jar,\
>> + lib/antlr-runtime.jar,\
>> templates/
>> src.includes = templates/,\
>> - src/,\
>> - plugin.xml,\
>> - build.properties,\
>> - META-INF/,\
>> - .project,\
>> - .classpath
>> + src/
>>
>> _______________________________________________
>> jbosstools-commits mailing list
>> jbosstools-commits(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-commits
>>
>>
>>
>
>
>
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
18 years, 10 months
Fwd: [jbosstools-commits] JBoss Tools SVN: r5304 - trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam.
by Max Rydahl Andersen
why are we adding new features and "largish" new antlr dependencies in
2.0.1 !?
-max
------- Forwarded message -------
From: jbosstools-commits(a)lists.jboss.org
To: jbosstools-commits(a)lists.jboss.org
Cc:
Subject: [jbosstools-commits] JBoss Tools SVN: r5304 -
trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam.
Date: Fri, 14 Dec 2007 13:40:11 +0100
Author: vyemialyanchyk
Date: 2007-12-14 07:40:10 -0500 (Fri, 14 Dec 2007)
New Revision: 5304
Modified:
trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/.classpath
trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/build.properties
Log:
http://jira.jboss.com/jira/browse/JBIDE-1449
Modified: trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/.classpath
===================================================================
--- trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/.classpath 2007-12-14
12:39:40 UTC (rev 5303)
+++ trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/.classpath 2007-12-14
12:40:10 UTC (rev 5304)
@@ -3,5 +3,8 @@
<classpathentry kind="src" path="src"/>
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
+ <classpathentry kind="lib" path="lib/ant-antlr.jar"/>
+ <classpathentry kind="lib" path="lib/antlr.jar"/>
+ <classpathentry kind="lib" path="lib/antlr-runtime.jar"/>
<classpathentry kind="output" path="bin"/>
</classpath>
Modified: trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/build.properties
===================================================================
---
trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/build.properties 2007-12-14
12:39:40 UTC (rev 5303)
+++
trunk/jsf/plugins/org.jboss.tools.jsf.vpe.seam/build.properties 2007-12-14
12:40:10 UTC (rev 5304)
@@ -3,11 +3,10 @@
bin.includes = META-INF/,\
.,\
plugin.xml,\
+ lib/,\
+ lib/ant-antlr.jar,\
+ lib/antlr.jar,\
+ lib/antlr-runtime.jar,\
templates/
src.includes = templates/,\
- src/,\
- plugin.xml,\
- build.properties,\
- META-INF/,\
- .project,\
- .classpath
+ src/
_______________________________________________
jbosstools-commits mailing list
jbosstools-commits(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-commits
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
18 years, 10 months
Testing the CA
by Victor V. Rubezhny
Hi Max.
Den asked me to answer on Automated Test Case creation possibility for
content assistant.
Amoung the JUnit test cases we have the one that tests OpenOn's region types
recognition. This tests contains the informatin for the specified file
region types and calls the OpenOn "detector" on each character position in
that file to ensure that the region types are properly detected.
So, for the CA we can create something like this. Because of algorithm of CA
invokation is closed deep inside ContentAssistant and
CompletionProposalPopup classes we have to write the same algorithm to get
the CA Processor for the source viewer and text position specified and then
aquire the processor for proposals.
There are some difficulties because of UI staff (there are too many private
and package local/internal classes in CA which need to, but cannot be
accessed from outside (from test case code)) but I think it's possible to
get the proposals for some test file.
The big question is how the test case can ensure that the proposal list
returned is the right proposals? There are too many variations for the
proposal set (depending on the JBoss and 3rd-party plugins installed and
project configuration it is possible to get a different set of proposals).
Best Regards,
Victor Rubezhny
18 years, 10 months
