The wizard needs ask few parameters one after the other. eg: name then address then email then passwd and finally send test mail.
If the send fails the wizard should start again. How can we implement this wizard.
Spring Shell is not really meant for "interactive, wizard style" programs like you describe. Rather "command-line style" applications where the user has the opportunity to provide the option values he knows about.
That being said, there is nothing stopping you from reading console input inside your command implementation. If this feature is the only aim of your program (i.e. you're not benefiting from more "classical" Spring Shell commands in the rest of the application), I would strongly advise to reconsider the use of Spring Shell altogether.
Spring Shell 3.0 recently went GA: https://spring.io/projects/spring-shell
Spring Shell does support wizard style console applications since version 2.1.0.
Checkout "Component Flow"
Starting from version 2.1.x, a new component model provides an easier way to create higher-level user interaction for the usual use cases, such as asking for input in various forms. These usually are just plain text input or choosing something from a list.
Related
I have a Hanami web app which interacts with SAP systems via vb scripts.
Is there an alternative way for Ruby which would enable the same level of interaction, i.e. connect to a system and perform some actions to either post or retrieve data from a system?
I've read about RFC and web services, but it seems they're no longer supported for Ruby. Or am I wrong?
EDIT------------------------
I currently have a web and a desktop app that basically do the same thing. Trgigger the execution of a vbs file as shown below:
stdin, stdout, stderr, wait_thr = Open3.popen3("cscript.exe //Nologo path/to/some_vbs_file.vbs #{#param1} #{#param2} #{#param3})
This way I get the data into the vbs and pipe it out as well.
However I've been looking for an alternate way, like mentioned here:
Ruby, Ruby on Rails, and SAP Web Services Integration
But some of the libs on ruby-lang.org are no longer accessible and the entire project is a bit outdated. So I wanted to ask if someone can advise where to look for an alternative, if any.
Thank you.
seba
I want to do ATDD with TDD and DDD and I want to first discover behaviors (using mocks) of a domain model (ecommerce in my example).
You can imagine that in DDD layering we can have application services calling domain services and repositories or other services and non business logic code, only tasks related to the application)
Please use the text below that I am trying to understand:
HOW TO USE MOCKS TO DISCOVER BEHAVIOUR OF MY ECOMMERCE DOMAIN AND THEN ENTER MORE GRANULAR TDD DEVELOPMENT TO IMPLEMENT DESIRED BEHAVIOUR.
This is an excerpt from another question (as an answer).
BDD, what's a feature?
"Pick whatever task that you need to implement, open a blank text file and try to explain using simple sentences the behavior. Every sentence should start with one of three keywords: given, when and then. Using your favorite BDD framework write the code that will parse these sentences and stimulate the application to get into the start state (given), execute some commands (when) and assert the transitioned state (then). Application code may start from mere mocks. Replace gradually those mocks with gradually built code and grow your application with higher confidence and quality levels."
Can someone provide some concrete examples of starting with mocks (RhinoMock, Moq) using two approaches:
1.Driving ATDD via Controller's actions and
2.Using Watin Driver (Page Objects, WatiN MVCContrib extensions) or Selenium.
If I am using no. 2. will I be able to see some example data when I visit some pages myself and do some actions ("When" I do something: navigate, post data) and validate results of these actions.
To fully understand the nature of my question please read this:
http://jockeholm.wordpress.com/2010/02/14/combining-tddbdd-with-ddd/
Especially Steps 3. and 4.
I will privide the text for step 3:
3.[BDD/ATDD] For each test scenario, implement an executable example that fails, since that behaviour is not supported by the system. Then, use outside-in development, with an extensive use of mock objects, to flesh out the behavior specified in the executable example.
Thanks,
Rad
This may help:
http://msdn.microsoft.com/en-us/magazine/dd882516.aspx
We are using Nant to deploy an application and need to create some MSMQ Queues during the process.
We use Nant/psexec/cscript to call a VBScript to create the queue itself but we also need to set the permissions.
Can this be done programmatically?
I am aware of Setting permissions on a MSMQ queue in script however that question asks for PowerShell or VBScript and has an accepted answer for PowerShell. We do not have PowerShell available to us so this question is specific to VBScript.
According to this post, MSMQ scripting API doesn't provide any means to set permissions on queries, so this task cannot be accomplished using VBScript.
I can suggest the following workarounds:
Use PowerShell, as illustrated in the post you linked to. (PowerShell can use the .NET Framework and, therefore, the MSMQ .NET API provided by the System.Messaging assembly.)
Create a custom utility that would set the necessary permissions and call this utility as part of your deployment process. For setting the queue security, you can use the following API functions:
MQSetQueueSecurity (in C or C++)
MessageQueue.SetPermissions (in .NET)
Just came across this and saw that it was unanswered. The trick here is to use VB.Net or C# code directly in nAnt. You can do this with a nAnt include, with a script task in the global space; and in the code, derive from the Task class.
Or. you can put your script block in a target. I prefer the former method, since it is easier to reuse and pass in parameters.
In either case, this is NOT VBScript, it is fully compiled .Net code, so you can do pretty much anything.
In your code element, Import System.Messaging, and create the Queue in your ExecuteTask override. Don't forget to give read/write/peek permissions to .\Users, or you probably don't be able to use the Queue properly except from the user that ran the nAnt script (which usually isn't the web server or Windows service that is reading the queue.)
Also, since you have full access to the Messaging.MessageQueue class, you can check for existence and delete an existing queue, or not!
I have an existing application written in Perl. Now I need to integrate this application with OBI. The plan is having a button the user can click on to open OBI in an iframe. OBI resides on a different server from the running application.
Has anyone done this before, know what is the best practice for doing this, and what is the effort of doing this?
Another question is is it possible to add customizations to the OBI displayed in the iframe.?
There are two ways to address the problem that I know of and tried out. According to your needs, one or the other might be more appropriate (or both, they're not mutually exclusive). In both cases, the documentation is good and readily available.
The "Go URL"
The Go URL is documented more thoroughly in the Oracle Business Intelligence Presentation Services Administration Guide. It provides a quick and easy interface to the reports you've already defined, in the form of a URL. All that's needed to get it running is to fill in a few query parameters to direct to the report you want. You might need to include authentication tokens too.
Pros: very easy to try out.
Cons: harder to get security right.
The web services
The presentation server comes with a series of web services that enable a more programmatic way of querying your repository. The functionality offered through this channel goes further: for example most catalog management, including report creation and editing is possible. The full list fills a guide of its own: the Oracle Business Intelligence Web Services Guide.
Pros: better integration (i.e., no need for an IFRAME); easier to get the security right.
Cons: harder to setup; lots of XML; more advanced features (e.g. in-place drilldown) need an HTTP bridge that was a bitch to get right in my case. The generated HTML might clash a bit with yours and require cleaning up, notably in the CSS.
Embedding OBIEE reports inside a non-ADF web app is tough. If you have an option to re-write your web application in ADF, your life will be a lot easier. Just drag and drop reports and visualizations into your web application. Oracle's own Fusion Applications also follow this approach. If your app is analytics heavy, it might be a good option to explore. Here's a link to the Oracle doc.
We maintain a system that has over a million lines of COBOL code. Does someone have suggestions about how to migrate to a GUI (probably Windows based) without losing all the business logic we have written in COBOL? And yes, some of the business logic is buried inside the current user interface.
If it was me I would look into something like this:
NetCobol for Windows
It should be fairly easy to wrap your COBOL with an interface that exposes the functionality (if it isn't already written that way) and then call it from a .NET application.
It took us about 15 years to get off of our mainframe, because we didn't do something like this.
Writing a screen scraper is probably your best bet. Some of the major ERP systems have done this for years during a transition from server based apps to 3-tier applications. One i have worked with had loads of interesting features such as drop down lists for regularly used fields, date pop ups and even client based macro languages based on the scraping input.
These weren't great but worked well for the clients and made sure the applications still worked in a reliable fashion.
There is a lot of different ways to put this together, but if you put some thought into it you could probably use java or .net to create a desktop based application and with a little extra effort make a web based implementation.
Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.
If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.
For program A, you then generate a client proxy and A can now call B via a web service.
Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.
Using this approach, you can "nibble away at the edges" to move the GUI to a modern, browser based approach using something like ASP while still utilising the COBOL business engine.
And once you have a decent set of web services, these can be used for any new development which provides a way of moving away from COBOL in the longer term.
You could use an ESB to expose the back-end legacy services, and then code your GUI to invoke the services via the ESB.
Then you can begin replacing the legacy services with implementations on your new platform of choice.
The GUI need not be aware of the cut-over of back-end service implementation, as long as the interface to the service does not change - minor changes may hidden from the GUI by the ESB.
Business logic that resides in the legacy user interface layer will need to be refactored by extracting the business logic and exposing it as new services on the new platform to be consumed by the new GUI via the ESB.
As for the choice of platform for the new GUI, why not consider a web-based UI rather than a native windows platform, then at least updates to the UI will only need to be applied to the web-server rather than having to roll-out changes to each individual work-station.