Using bookmarks to jump from any point in the story is a very useful feature. But can we use Jump and bookmark to jump from one story to another? It seems to be possible as the bookmarks drop-down shows all the bookmarks across the stories not just the bookmarks within the story. But my doubt is how will it recognize the intent of the new story to be executed.
Any example of wit application would be helpful.
Thanks in advance.
I answered with a homemade solution here wit.ai - unrecognised user entries
Essentially, you can create an action call "jumpTo[Insert-Your-Story-Name]Story". On your side, this action "emulates" the fact that the users sent a pre-determined message that will triggered your another story.
It works, but I don't know if it's the best way to do it.
Related
Similar to the functionality of using a form formula in a view, I would like to figure a way to provide someone with a link to a document via a URL and have it open in an alternate form. I'm trying not to modify the actual form value on the document, that gets messy to keep straight.
The form is a very complicated form with tabbed tables and 90% admin data, but I would like to turn over the maintenance of just one small set of fields to the user community without them seeing everything else.
Is there a way to force a link to open it BY WAY OF A VIEW that has a form formula? That is what I am thinking. Either that or I create/populate some smallish document when providing the link, then send them a link to this smaller document and have it update the 'parent' in it's webquerysave event.
Thanks,
Matt
If you want to open the document in Notes, you could try to send them a notes-URL, in the form of
notes://yourServer/yourDatabase.nsf/yourView/yourKey?OpenDocument
I remember having a conversation about this with one of the original developers of the Domino web server many, many years ago -- but I wasn't 100% certain that I remembered the answer correctly. So, I just searched through my old documents looking for a draft of the article I was writing when I had that conversation (in 1997!). It turns out that I didn't cover it in that particular article, but I did cover it several years later in one of the chapters that I wrote for the Lotus Notes & Domino 6 Programming Bible
You may be wondering why, since a UNID uniquely identifies any note, is it necessary to include both a Document UNID and a View UNID in a URL. The same question actually applies to doclinks, which were discussed above. The truth is that you don’t have to include a View UNID in either case, but it does serve a purpose if you do. You can replace the View UNID in a URL with a zero, retaining the slash characters that surround it. If you do this, Domino will not be able to execute a Form formula, which you may have included in the code of one or more Views in your application. See chapter 15 for more information about Form formulas.
In other words, if you include the UNID of a view that has the Form Formula that you wnat in the ?OpenDocument URL that you are sending to the server. The Form Formula will be respected.
I followed the quick start guide and was able to complete it.
However, when i tried testing the branch action then followed by the initial action where the parameters are complete it keeps on responding with a question triggered by the branch action.
How do I resolve this?
I think your second scenario where the user doesn't specify a location should go into a sparate story:
From Wit.ai documentation:
You will teach Wit by example, and each example conversation is called a Story
So from what i understand a story needs to handle one initial input.
I'm having a bit of a trouble understanding how to fit a particular design flow I have into a proper REST architecture. Let me explain the flow:
I'm creating technical support website where users can submit ProblemRequests. On the front page, the user selects all the categories he's having trouble with and clicks "get help," which then redirects him to the next page where he fills out some forms to submit his request. Here are the pages:
Page 1 - Select Problem Categories
Page 2 - Fill out Problem Request
Page 2 basically acts like the NEW action for a ProblemRequest. The thing is each ProblemRequest depends on multiple ProblemCategories, so a nested route isn't going to work here. The next thing that comes to mind is sending in all relevant ProblemCategories ids as an GET param for the NEW ProblemRequest action, but I would rather not expose the IDs in the URL.
A Multi-Part form sort of comes to mind, but that involves making ProblemRequests have state, where some would be complete and others incomplete. I don't want to deal with the implications, because in reality this is a one page submission, not a very long-winded process.
What would work ideally is to override the NEW action for the ProblemRequests controller to respond to POST operations, but I don't know if this is considered bad programming practice. Is this a cardinal sin? Is it okay for me to change the NEW action to respond to POST instead of GET?
Please advise,
Thanks in advance.
Keep it simple. Is there any reason for the round-trip to the server? I'd just make the two "pages" a single page and maintain the state of the selected categories client-side.
Use a multi-step form: http://railscasts.com/episodes/217-multistep-forms
You can save the IDs in the session, and the model won't get saved in the DB until you are finished filling out the info. Works great for simple 2 or 3 step forms.
For more complex wizards you could use a gem like https://github.com/schneems/wicked
I'm working on a Rails application. Two of my models are notes and attachments. The user can create notes and add attachments to them. This is standard stuff and I already have this working fine.
Currently, the user must create a note before they can add attachments to it. I'm looking to implement a more streamlined workflow for the user, similar to the familiar email workflow where you can add attachments to an unsaved email. However, the key is that I don't want the user to even have to save a draft of the note before the attachment can be added, and I want this unsaved note to be abandoned if the user navigates away (I don't want to have the additional complexity of unsaved/unpublished notes).
I know that when the note hasn't initially been saved yet, I can create the attachments without the link to the note, and then establish the link when the note gets saved. The part I'm drawing a blank on is how do I remove the unused attachments if the user breaks off the note creation process? Is there a hook that I'm missing that allows me to see that the user broke off?
Without such a hook, the first solution that comes to mind is a nightly cleanup script that runs via cron that would find all of the unattached attachments and remove them (perhaps filtering by attachments that have been created more than 24 hours ago). Is this the best solution?
There really isn't any kind of trigger to let you know when to clean those up, since a user can just leave the site without "logging out" or some other action. So that leaves you with a background job not attached to user action. In your case I think a nightly cron is nice and simple and would fit this situation well.
I have a web form which the users fill and the info send to server and stored on a database. I am worried that Robots might just fill in the form and I will end up with a database full of useless records. How can I prevent Robots from filling in my forms? I am thinking maybe something like Stackoverflow's robot detection, where if it thinks you are a robot, it asks you to verify that you are not. Is there a server-side API in Perl, Java or PHP?
There are several solutions.
Use a CAPTCHA. SO uses reCAPTCHA as far as I know.
Add an extra field to your form and hide it with CSS (display:none). A normal user would not see this field and therefore will not fill it. You check at the submission if this field is empty. If not, then you are dealing with a robot that has carefully filled out all form fields. This technique is usually referred to as a "honeypot".
Add a JavaScript timer function. At the page load it starts a value at zero and then increases it as time passes. A normal user would read and fill out your form for some time and only then submit it. A robot would just fill out and submit the form immediately upon receiving it. You check if the value has gone much from zero at the submission. If it has, then it is likely a real user. If you see just a couple of seconds (or even no value at all due to the robots not executing JavaScript) then it is likely a robot. This will however only work if you decide you will require your users have JavaScript on in order to perform "write" operations.
There are other techniques for sure. But these are quite simple and effective.
You can use reCAPTCHA (same as stackoverflow) - they have libraries for a number of programming languages.
I've always preferred Honeypot captcha (article by phil haack), as its less invasive to the user.
Captchas bring accessibility problems and will be ultimately defeated by software recognition.
I recommand the reading of this short article about bot traps, which include hidden fields, as Matthew Vines and New in town already suggested.
Anyway, you are still free to use both captcha and bot traps.
CAPTCHA is great. The other thing you can do that will prevent 99% of your robot traffic yet not annoy your users is to validate fields.
My site, I check for text in fields like zip code and phone number. That has removed all of the non-targeted robot misinformation.
You could create a two-step system in which a user fills the form, but then must reply to an e-mail to "activate" the record within a set period of time - say 24 hours.
In the back end, instead of populating your current table with all the form submissions, you could put them into a temporary table that automatically deletes any row that is older than your time allotment. Unless you have a serious bot problem, then I would think that the table wouldn't get that big, especially if the first form is just a few fields.
A benifit of this approach is that you don't have to use captcha or some other technology like that that might create some accessibility problems.