11:34 p.m.
Those are some excellent questions, I'll answer then inline:
Em 01/09/2013, às 17:15, "Ivan St. Ivanov" <ivan.st.ivanov(a)gmail.com>
escreveu:
Hey folks!
This weekend I've been hacking on migrating the git-tools to Forge 2
(https://issues.jboss.org/browse/FORGE-1128). And I can say that I have pretty much
finished the task (although I haven't started yet with the git-tools-tests, but I will
do that as well).
And I have the following questions and observations:
1) How do you declare that a UI command requires to be executed in the context of a
project or in a context of a certain resource? In Forge 1 we had the @RequiresProject and
@RequiresResource annotations, but now we only have @RequiresFacet (I hope it works ;)).
What I do here is: implement isEnabled and work with the initialSelection method of the
UIContext to check what is selected. BTW I find quite more declarative approaches in Forge
1 than in Forge 2.
Exactly, this is the way to do it. We haven't migrated @RequiresProject and
@RequiresResources yet, so you're doing the right thing.
2) In Forge 1 we had one plugin class that represented a command with
a lot of options as methods of that class. Did I get it right that in Forge 2 I have to
create a separate UICommand implementation for every option (i.e. method) of the plugin
class? I don't say it's bad, I just want to understand whether this is the way
Right again. We prototyped in a separate branch the "command-per-method"
strategy but we haven't completed it yet.
3) How do you get the current resource (@Current as of Forge 1)? Is
it context.getInitialSelection().get()? How can I check that it is of any particular type
(e.g. GitIgnoreResource)?
Yes, the current resource is always retrieved using UIContext.getInitialSelection,
which can be safely assigned to a UISelection<Resource<?>> variable.
4) Is there such a thing as setup command? I think there's no
need, but still I'd like to ask
There is not, but setup commands should be implemented as UICommands as you may
have already noticed.
5) If a facet has to write a message to a provider (GUI, shell), how
does it do it? Commands do that via the Result object, but I didn't get how facets
can. Or should they at all write anything?
Facets can't write messages for now, but we should consider doing it so it if
makes sense.
6) I saw that some of the git commands in Forge 1 fire pickup
events:
Event<PickupResource>::fire(new PickupResource(gitIgnoreResource()));
How is this done in Forge 2. I would appreciate a sample in existing plugin
You have to call UIContext.setSelection in your UICommand.execute method.
7) How did you migrate existing completers? I see that the completer
interface has changed. I am afraid I can't figure out how I can rework complete
methods from Forge 1, that were using CommandCompleterState parameter. I couldn't find
samples
In the UICommand.initializeUI method, you call setCompleter for the desired
injected input
And of course I have some questions about the git-tools
implementation that have nothing to do with the migration:
1) At the moment the GitUtils class, which I have made an interface and plan to export as
addon, exposes some JGit classes as parameters. Do you think it's a good idea to wrap
them in our own classes like you have done with the JDT parser API for example?
That would be a good idea, so it could be possible to use native git if needed.
2) I see that in javaee-impl you have implemented an abstract command
class that exposes a class that returns the current project (or null):
org.jboss.forge.addon.javaee.ui.AbstractProjectUICommand. I copy-pasted the
getSelectedProject method to an abstract Git UI command class that I created just becayse
I saw that addon-ui does not have access to the project API (outherwise I would put it in
the AbstractUICommand class). Can we find a better place for this code? In Forge 1 we just
@Inject-ed a Project instance, but now I am not sure what to do
Make your addon depend on the projects addon and you shall access these classes
normally
So, that's all from me for now. Next to come - the questions
about the migration about the tests ;)
Bring'em on! :)
Cheers,
Ivan
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev