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