[forge-issues] [JBoss JIRA] (FORGE-2615) Forge addon - From one command be able to easily split into a wizard with N pages

[Claus Ibsen (JIRA)]

    [ https://issues.jboss.org/browse/FORGE-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174935#comment-13174935 ] 

Claus Ibsen commented on FORGE-2615:
------------------------------------

>From the chat today with ggastaldi

[15:10:53]  <davsclaus>	one thing i thought of this morning that would be nice
[15:11:08]  <davsclaus>	was having 1 class being able to have the ui elements and the execute 
[15:11:10]  <davsclaus>	as today
[15:11:17]  <davsclaus>	but being able to mark some of the uis
[15:11:18] 	ggrzybek is now known as ggrzybek_bbl
[15:11:20]  <davsclaus>	to be on page 2, 3 etc
[15:11:29]  <davsclaus>	and then forge automatic turn that into a wizard with next/back
[15:11:47]  <davsclaus>	so you dont have to move it into new UIStep classes and whatnot
[15:11:51]  <davsclaus>	but can keep it all in 1 file
[15:11:59]  <@gastaldi>	hmm
[15:12:02]  <davsclaus>	for those simpler commands where
[15:12:10]  <davsclaus>	you start with 3-4 ui\s
[15:12:17]  <davsclaus>	and then add some more and then you have 8 or so
[15:12:26]  <davsclaus>	and find out it makes the ui better if it was 2 pages
[15:12:26]  <@gastaldi>	right, I think we can have a command that splits that into multiple UISteps internally
[15:12:32]  <davsclaus>	yep
[15:13:25]  <@gastaldi>	or a fluent language builder
[15:13:49]  <davsclaus>	yeah
[15:13:55]  <@gastaldi>	something like: Command.named("").having(UIInput, UIInput)
[15:14:15]  <davsclaus>	builder.add(one).add(to).next().add(three).add(four).next().add(five);
[15:14:27]  <davsclaus>	in that initializeUI method
[15:14:31]  <davsclaus>	where you add the ui elements
[15:14:34]  <@gastaldi>	ah you mean the UIBuilder
[15:14:56]  <davsclaus>	yeah
[15:14:58]  <@gastaldi>	hmm
[15:15:13]  <davsclaus>	the pain today is to break up your command into N steps in the wizard
[15:15:18]  <@gastaldi>	I see
[15:15:23]  <davsclaus>	for simpler uis that is just straight line
[15:15:37]  <davsclaus>	i can understand the complex ones you need more code and to code in the next() etc
[15:15:44]  <davsclaus>	but for 90% ui's
[15:15:54]  <davsclaus>	its N options you want to show the users
[15:15:56]  <davsclaus>	but not all at once
[15:16:02]  <davsclaus>	to not overload/confuse the user
[15:16:07]  <davsclaus>	but spread out in N pages
[15:16:21]  <davsclaus>	having all that in 1 java file
[15:16:27]  <@gastaldi>	what about the conditions of showing an Input on a Nth page?
[15:16:27]  <davsclaus>	makes it easier to code and "overview"
[15:16:46]  <davsclaus>	from forge pov it is as if all the options are on the same page
[15:16:56]  <@gastaldi>	right, I see
[15:16:59]  <davsclaus>	but imageing people dont have big monitors
[15:17:15]  <davsclaus>	so somehow it automatic overflow
[15:17:27]  <davsclaus>	that can work for the simpler cases
[15:17:38]  <davsclaus>	if you need conditional and branches, or whatnot
[15:17:41]  <davsclaus>	then you can code it
[15:18:30]  <@gastaldi>	by overflow you mean automatically adding a vertical scroll bar to the Wizard panel?
[15:19:02]  <davsclaus>	if you add to many options to a command then today it will show a dialog
[15:19:06]  <davsclaus>	that cannot fit the screen
[15:19:10]  <davsclaus>	an you cannot see all the options
[15:19:15]  <davsclaus>	and the next / finish button either
[15:19:29]  <davsclaus>	that is okay if you keep to max 20-30 options etc
[15:19:36]  <davsclaus>	but that happens seldom
[15:19:40]  <@gastaldi>	in any IDE? or is that just in Eclipse?
[15:19:45]  <davsclaus>	any of them
[15:19:52]  <@gastaldi>	gotcha, that looks like a bug 
[15:20:06]  <davsclaus>	i dont think anyone builds ui like that
[15:20:15]  <davsclaus>	we only see it in those camel wizards with camel endpoints
[15:20:22]  <davsclaus>	where you have maybe 90+ options
[15:20:37]  <davsclaus>	and we do not want 90 on one page either
[15:20:45]  <davsclaus>	so that is why we have that dynamic wizard with the camel
[15:20:46]  <@gastaldi>	right. What if you could split these options into fine grained commands?
[15:20:53]  <davsclaus>	where we compute how many pages and all that
[15:21:07]  <davsclaus>	i cannot its 100% dynamic
[15:21:12]  <@gastaldi>	Right
[15:21:23]  <davsclaus>	that is okay, its all the other commands i talk about really
[15:21:31]  <davsclaus>	we often have commands with 4-10 options
[15:21:36]  <davsclaus>	but would like 2 or 3 pages
[15:21:42]  <davsclaus>	instead of 1
[15:21:50]  <davsclaus>	and today i have to code a fair bit to do that
[15:21:56]  <@gastaldi>	I see
[15:21:58]  <davsclaus>	hence why i would love to keep it in 1 java file
[15:22:10]  <@gastaldi>	right 
[15:22:15]  <davsclaus>	and just tell forge that these X inputs = page 1, these Y inputs = page 2
[15:22:34]  <@gastaldi>	or have Forge automatically calculate that for you
[15:22:36]  <davsclaus>	and optionally be able to set the title for each page as well
[15:22:39]  <@gastaldi>	like, 10 elements/page
[15:22:45]  <davsclaus>	yeah that too
[15:23:02]  <davsclaus>	but often you may want only these 3 together as they are kinda grouped
[15:23:04]  <davsclaus>	and then on next page
[15:23:06]  <@gastaldi>	hmm, that's something to think about, would you mind JIRAing this? 
[15:23:14]  <davsclaus>	ok

> Forge addon - From one command be able to easily split into a wizard with N pages
> ---------------------------------------------------------------------------------
>
>                 Key: FORGE-2615
>                 URL: https://issues.jboss.org/browse/FORGE-2615
>             Project: Forge
>          Issue Type: Feature Request
>          Components: UI - API
>    Affects Versions: 3.0.0.CR1
>            Reporter: Claus Ibsen
>
> Problem
> When you build commands in forge that you want to be like a wizard, with 3 pages, where you on page 1 have 3 inputs, on page 2 4 inputs, and on page 3 2 inputs. Then today you need to build that in multiple classes with UIStep and initialize the ui for each step, and put them all together and whatnot.
> This seems sometimes a bit too much for those simpler commands, where basically you wish you could write all that in just *one* java class. And then tell forge to split the UI elements into 3 pages, and tell it which UI elements go into what page. Then forge makes that automatic a wizard with next/back/finish buttons.
> Then from the logic point of view. It works 100% as if would do if there was just 1 page with all the inputs on the same page. So validation / listeners and so on all react. 
> The idea is just to allow the end user to much easier break this up into steps that makes the command better to use for end users. You may on the first page to have ui fields that take in some mandatory fields, and then on page 2 some fields that are related together in some way, and then on page 3 yet another group of related options.
> You should also be able to configure the title of each page in that steps. So maybe you can in the initiizeUI method do:
> {code}
> builder.add(one).add(to).next().add(three).add(four).next().add(five);
> {code}
> Notice how we use next to tell forge that we want the following inputs on the next page.
> Or maybe you can specify the title also as:
> {code}
> builder.add(one).add(to).nextWithTitle("Configure foo stuff").add(three).add(four).nextWithTitle("Configure bar stuff").add(five);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)