2:24 a.m.
Victor, please remember to reply-all and not just me ;)
Victor V. Rubezhny wrote:
In old CA we've used a knowledge base that had all the data on
tags/attributes/enumerations stored in XML-formatted files for each TLD and
schema that might be used by a user. There were the tons of XMLs for all
the known TLDs/Schemas we have had to support. Many of these XMLs were
generated by the converter program but finally almost all of them were
edited by the hand to specify some default tag attributes or default
attribute values or descriptions etc. It was really hard to support and
renew all this staff.
Ok. Don't we have a way of "enhancing" the completions today in
case the
metadata is not complete ?
or is that just not relevant anymore ?
Of course, as the second part of CA there was a dynamic part which
proposed
a user with dynamic things like actions, path, images and other dynamic
values within the project.
Yes...but these does not require a builder nor nature to be in place do
they ?
We should try and fail gracefully in case of missing information...
btw. now that the "global" cache is gone are the completions as good as
before ?
Are there some things missing compared to before which we could get from
the old knowledge base but
not the new ?
As the result of CA refactoring we turned to use dynamic KB
generation
depending on the libraries used in the project. All the special things (such
as predefined values, default tag attributes , default attribute values and
so on) are stored in slightly compact difference XMLs, but all the other
things are generated automatically for each library used in the project.
Okey....
We saved the disk space (because we don't need to store the tons
of
information on each Tag library in the world) and the time (because we don't
need to prepare XMLs for each new library by the hand), but now we need a
builder that's doing this work for us on startup and on the fly if a user
adds some new library to its project.
We do cache these things, right ? If we do this per project aren't we
going to add a massive overhead ?
Probably you're right and I'll be able to start KB-builder
(and prepare the
.project file) when the CA will generate an error. But the builder takes a
time to parse all the libraries used in the project and its dependencies,
Yes, but
then why not have the code completion show a completion that
says: "Enable JSF(?) code completion on this project" in
case it is not there and if users select that install the builder/nature
? btw. can't we avoid having these builders/natures
if we already got one of our jsf/seam/you-name-it builders/validators
already installed ? Just trying to avoid creating
too many events.
so
I suppose that the kosher way is to set up a builder and KB-nature at
project startup, but not when a user wants to be prompted with something.
Well, for existing projects there is no such thing as "project
startup" ....
/max
5:36 a.m.
New subject: [Fwd: [JBoss Tools (users)] - Project MYPROJECT doesn't have KB nature.]
Victor, please remember to reply-all and not just me ;)
I'm, sorry. I forgot.
Victor V. Rubezhny wrote:
> In old CA we've used a knowledge base that had all the data on
> tags/attributes/enumerations stored in XML-formatted files for each
TLD and
> schema that might be used by a user. There were the tons of XMLs for
all
> the known TLDs/Schemas we have had to support. Many of these XMLs
were
> generated by the converter program but finally almost all of them
were
> edited by the hand to specify some default tag attributes or default
> attribute values or descriptions etc. It was really hard to support
and
> renew all this staff.
>
Ok. Don't we have a way of "enhancing" the completions today in case
the
metadata is not complete ?
or is that just not relevant anymore ?
At the moment (with new CA) it doesn't matters on what libraries are used
within the project - we'll generate proposals on any library included (And
event on a user's self made libraries)
> Of course, as the second part of CA there was a dynamic part
which
proposed
> a user with dynamic things like actions, path, images and other
dynamic
> values within the project.
>
Yes...but these does not require a builder nor nature to be in place do
they ?
We should try and fail gracefully in case of missing information...
btw. now that the "global" cache is gone are the completions as good as
before ?
Are there some things missing compared to before which we could get
from
the old knowledge base but
not the new ?
Of course no builder nor nature required to generate dynamic proposals (such
as default attributes for tags to insert or some known attribute values to
propose). But we need something to collect the information on libraries used
in the project and its dependencies. Users may add or remove the libraries
to/from their projects during the project development. And we suppose that
to have a builder to collect this information and process the changes is
most cheapest and effective way. The completion now is even more complete
and actual than it was before.
On the libraries (TLDs and Schemas) there is missing things (even more: now
we have completions for any library used in a project).
We converted all the dynamic knowledge base stores (they were used to
generate dynamic proposals depending on the project structure) to the new CA
libraries. It has to cover 100% of old CA functionality.
> As the result of CA refactoring we turned to use dynamic KB
generation
> depending on the libraries used in the project. All the special
things (such
> as predefined values, default tag attributes , default attribute
values and
> so on) are stored in slightly compact difference XMLs, but all the
other
> things are generated automatically for each library used in the
project.
>
Okey....
> We saved the disk space (because we don't need to store the tons of
> information on each Tag library in the world) and the time (because
we don't
> need to prepare XMLs for each new library by the hand), but now we
need a
> builder that's doing this work for us on startup and on the fly if a
user
> adds some new library to its project.
>
We do cache these things, right ? If we do this per project aren't we
going to add a massive overhead ?
> Probably you're right and I'll be able to start KB-builder (and
prepare the
> .project file) when the CA will generate an error. But the builder
takes a
> time to parse all the libraries used in the project and its
dependencies,
Yes, but then why not have the code completion show a completion that
says: "Enable JSF(?) code completion on this project" in
case it is not there and if users select that install the
builder/nature
Yes we can have such completion proposal.
? btw. can't we avoid having these builders/natures
if we already got one of our jsf/seam/you-name-it builders/validators
already installed ? Just trying to avoid creating
too many events.
This is a question to Alex.
But IMHO, the incremental builder doesn't take too much time to update the
structure, so it doesn't make an overload to the JBoss Tools performance.
> so
> I suppose that the kosher way is to set up a builder and KB-nature at
> project startup, but not when a user wants to be prompted with
something.
>
Well, for existing projects there is no such thing as "project startup"
....
I supposed that. But the way you proposed (to have a special completion
proposal to enable JSF code completion on a project) would be a good
solution.
/max
6:35 a.m.
New subject: [Fwd: [JBoss Tools (users)] - Project MYPROJECT doesn't have KB nature.]
> and
>
>> renew all this staff.
>>
>>
> Ok. Don't we have a way of "enhancing" the completions today in case
> the
> metadata is not complete ?
> or is that just not relevant anymore ?
>
At the moment (with new CA) it doesn't matters on what libraries are used
within the project - we'll generate proposals on any library included (And
event on a user's self made libraries)
Yes - that was the goal - but I just had the understanding that the old
KB knowledge base for some libraries
contained more info than what were derivable from TLD's etc. ?
> Yes...but these does not require a builder nor nature to be in
place do
> they ?
> We should try and fail gracefully in case of missing information...
>
> btw. now that the "global" cache is gone are the completions as good as
> before ?
> Are there some things missing compared to before which we could get
> from
> the old knowledge base but
> not the new ?
>
Of course no builder nor nature required to generate dynamic proposals (such
as default attributes for tags to insert or some known attribute values to
propose).
Good - so the nature/builder is not a requirement for this part ?
But we need something to collect the information on libraries used
in the project and its dependencies. Users may add or remove the libraries
to/from their projects during the project development. And we suppose that
to have a builder to collect this information and process the changes is
most cheapest and effective way.
Yes, I understand this - but the builder is only
needed for incremental
building of this, correct ?
Without it we could still trigger a scanning on first completion and
then have a manual way of updating it
- i.e. have a "Rescan for JSF" button under project preferences - and
have an option to install the nature/builder
there too for more efficient collection.
This would allow any java project to have this feature or at least some
of it enabled.
The completion now is even more complete
and actual than it was before.
Cool ;)
On the libraries (TLDs and Schemas) there is missing things (even
more: now
we have completions for any library used in a project).
We converted all the dynamic knowledge base stores (they were used to
generate dynamic proposals depending on the project structure) to the new CA
libraries. It has to cover 100% of old CA functionality.
Okey - sounds great then ;)
>> adds some new library to its projec.
> ? btw. can't we avoid having these builders/natures
> if we already got one of our jsf/seam/you-name-it builders/validators
> already installed ? Just trying to avoid creating
> too many events
This is a question to Alex.
But IMHO, the incremental builder doesn't take too much time to update the
structure, so it doesn't make an overload to the JBoss Tools performance.
Well - together with all the other validators and builders we got
running even the smallest builder can be
an overhead for workspaces with even just a few but big projects...but
lets just have this as a topic to be
aware of when Alexey returns.
>> so
>> I suppose that the kosher way is to set up a builder and KB-nature at
>> project startup, but not when a user wants to be prompted with
>>
> something.
>
> Well, for existing projects there is no such thing as "project startup"
> ....
>
I supposed that. But the way you proposed (to have a special completion
proposal to enable JSF code completion on a project) would be a good
solution.
Or do the scanning automatically the first time and have a way as
described above to enable the
incremental one for old or non-jsf projects in preferences ?
/max
5623
days inactive
5623
days old
jbosstools-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Max Rydahl Andersen -
Victor V. Rubezhny