Multiple branches to the same page

Question

A few questions about branches...
1. Having a branch back to the same page with a 'when button pressed=Submit', another branch back to the same page with some other button-press condition, etc are all redundant, right?
It is sufficient to have just one unconditional branch back to the same page, right?
2. What is the difference between branch type 'branch to page or url' and simply 'branch to page'? Does the former cover the latter, so why do we need two types?
3. Anyway, when I choose the latter, there is a checkbox below the page number for 'branch to page using redirect'. What does this mean?
4. I have always seen the 'On submit: after processing' branch point being used. When would the other branch points be used?
Thanks

Answer 1

Vikas,
1. No, they are not "all redundant" nor is any
individual one. What if your page is submitted in
some way other than by one of the buttons evaluated
in the branch definitions?
Right, thats why I said "It is sufficient to have just one unconditional branch back to the same page, right?". Why is it not sufficient to have just 1 unconditional branch? That would cover all the cases. Each page process can then check for whatever conditions it needs?Ummm, you say "Right" to my rebuttal and then you restate your original premise -- that logic eludes me. Let me offer this: Ponder my question, exactly as I wrote it, and consider self-submitting items, tabs, javascript, fields that submit the page when you hit Enter, etc., then it might make more sense. I don't think I can help you with that last part "Each page process..." even if it were an actual question.
2. A Branch to Page (aka direct branch) calls the
target page directly from accept processing without
using a URL redirect. The other type redirects.
Maybe this has nothing to do with HTMLDB, but whats the difference between "directly from accept processing" and "redirect"?Fair question. When you submit a page, wwv_flow.accept processes it. When it finishes, it evaluates the branching logic to determine what page you see next and then either redirects to that page (to f?p=...) or calls wwv_flow.show in the same database session (direct branch).
3. That's a way of creating most branches as URL
redirect branches when the developer isn't paying
attention. Uncheck the box to "really" create a
direct branch.
You seem to be implying that a "direct branch" is not really desirable in most cases? Why? (I guess your answer to my question above will clear this up for me)Well, they're usually not the best choice. You end up with "wwv_flow.accept" in the browser location window after the branch and using the browser's back button to go back to those requests gives you that annoying "page contains POSTDATA" message. Those branches can be useful if you want to stay in the same database session for page processing (after submit) and the subsequent page view, such as in the case of inline validation errors where package state is maintained. The checkbox (default checked) technique is to require developers to really think about a choice that may have been reflexive.
4. Please read the User's Guide.
I did. Lets take them 1 by one
a. On submit, before computation: The docs say this is to be used for a Cancel button. But wouldnt a javascript:document.form.reset() do the same thing?A Cancel button that submits the page does just that, it submits the page, allowing session state to be saved and any logic on the page to be performed before the correct branch is taken. You ask whether that javascript would do the same thing. The same thing as what, the Cancel button? No!
b. on load before header: "...displays another page instead of the current page...". But then why wouldnt I just create a branch of some other branch point with that "another page number" in the first place?Because sometimes it's better for page X to decide to go to page Y before doing much of anything than for N callers of page X to make the same determination.
I guess I am having difficulty understanding the concept of a "branch point". As you said elsewhere, a branch doesnt contain any logic, it doesnt call anything, it just branches to some page/url.Where did I say that?
So, why have all these different branch points? What advantage does having this fine degree of control provide us? (as opposed to always 'on submit: after processing'?)Your proposal about reviewing various branch points was "Lets take them 1 by one", but then you skipped three of them. Please read the entire section on branching, create pages with all possible types of branches and a variety of buttons and conditions, experiment extensively with them and let us know if it's still unclear. I think you'll find, over time, that all features
in HTML DB are there for a good reason. The developers found a need for them developing real applications. Where capabilities were missing, features were invented and added,
where features seemed useless, they were dropped/deprecated. The tool you see today has been evolving for years. I think it's unreasonable to expect to be able to
appreciate the value of every single feature until you've been using HTML DB for a couple of years.
Scott