[forge-dev] Questions about migrating git-tools to Forge 2

[Ivan St. Ivanov]

Hey George!

Thanks a lot for the quick feedback!

I'm afraid though that I did not get some of the answers I needed:

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)*?

[George]: Yes, the current resource is always retrieved using
UIContext.getInitialSelection, which can be safely assigned to a
UISelection<Resource<?>> variable.

[Ivan]: I did not get how can I check whether a file resource is of
GitIgnoreResource type. What I can think of: check whether the current
resource is file and that its name is GitIgnoreResource.RESOURCE_NAME. I'm
afraid that instanceof will not work. What I am not sure is how Forge knows
that a certain resource is of certain type (or more precisely: of certain
subtype of FileResource)


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

[George]: In the UICommand.initializeUI method, you call setCompleter for
the desired injected input

[Ivan]: Yes, I found how to assign a completer to an input. However I was
not sure how to adapt an already existing completer, which received as
parameter a CommandCompleterState object. The existing completers used that
object and I don't know how to rework them to use the UIContext interface
for the same purpose


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

[George]: Make your addon depend on the projects addon and you shall access
these classes normally

[Ivan]: Actually I did what you proposed. But now we have one and the same
"protected Project getSelectedProject(UIContext context)" method
in org.jboss.forge.addon.javaee.ui.AbstractProjectUICommand and
in org.jboss.forge.addon.git.ui.AbstractGitCommand. Can we find a better
place for a class like AbstractProjecUICommand that is accessible from
anywhere where we develop commands relying on a context of a project? Maybe
in projects-impl? Both javaee and git depend on that.


And one additional question:

8) In Forge 1 every plugin had a short name that we entered on the command
line. Now I see that commands have some long strings as names (e.g. "JPA:
New Entity"). What does the user have to enter in the shell if they want to
create a new entity?

Thanks,
Ivan


On Mon, Sep 2, 2013 at 12:34 AM, George Gastaldi <ggastald at redhat.com>wrote:

> Those are some excellent questions, I'll answer then inline:
>
> Em 01/09/2013, às 17:15, "Ivan St. Ivanov" <ivan.st.ivanov at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130902/6253766f/attachment-0001.html