ХБ,

At this point the combobox is not editable. I added this to our issue tracking system as an enhancement request. If you create a question about this in our Q&A forum then other users may vote it up which will speed things up. :-)

Hi,

To mimic a block based on a procedure in Formspider, you may use a view with an instead of trigger. If you want the rows to be returned from PL/SQL instead of SQL, you may use a select * from table(myfunction(input1,....)...) construct and return an Object Collection from a PL/SQL function.

There are two ways to alter the where clause in Formspider.

1. You may use bind variables in your DSD (Datasource Definition) and set the bind variables using the api_datasource.setBindVar API and then execute the query of the datasource using the api_datasource.executeQuery API. This is the most common use case.

By the way here is the API doc: http://theformspider.com/API/index.html

2. You may also use api_datasource.setFilter API to achieve a similar effect without re-querying the datasource rows from the database. But this is a rarely used method. I'd recommend going with the first way. The tutorials 2-8 in the Learning Center go over the basics of how to use method 1. http://theformspider.com/learningcenter/

3. There is going to be a third way in the next version of Formspider (version 1.2) which will allow you completely changed the query of your datasource using api_datsource.setQuery API (as long as it returns the same column list). This will help developers to fine tune the SQL for different kind of queries users perform.

Do you have an Formspider Online account? We can put a more complicated reference application to your Formspider Online account if you open one.

Hi,

Ye,s there is a Question and Answer (Q&A) site: http://osqa.theformspider.com/ . It is the Q&A link in the menu of the web site.

There is no reason copy the Forms "populate from procedure" feature 1 to 1 in Formspider. Since Formspider runs in the database we can take advantage of things that already exist in the database like views with instead of triggers and SQL based on PL/SQL functions. As I mentioned, use a function in your DSD query that returns a collection type and use an instead of trigger with a view to handle your DML. I think this provides the same flexibility that the procedure based block does. Do you agree or am I missing something?

There are four tree tutorials. They are all named tutorial 10. (Part I, II, III, IV). They all talk about different aspects of the tree component. The Formspider tree is a complete component with all the features you mentioned. The four tutorials together give the complete picture. If you can't find what you are looking for in them, please ask a question in the Q&A site and we'll be happy help.

Check out your Formspider Online account. There is probably an application called SR_Demo in your account which is our reference application. The source code (PL/SQL) should also be in your schema.

I will double check tomorrow morning and install the application to your account if it is missing but I think it should be there.

See you in the Formspider forum. :-)

Hi,

We just deployed our reference application to your online account. We are in the process of documenting it. The first four chapters are in the learning center. Here is the fourth one. It has links to the previous three: http://theformspider.com/learningcenter/service-company-tutorial-chapter-4-implementing-internalization-infrastructure/

Hi Stan,

Thank you for your honest feedback. I truly appreciate it. Please allow me to comment on them.

1. Tree
I understand how you feel. I felt the same way initially about the tree. However, after using it for a while, i realized that it is actually not that different from the Forms tree. If you look carefully to the code you wrote to the Q&A page and the Formspider example Ibrahim wrote, the query differs only in that Formspider one is only slightly different. I think it has one bind var and two additional restrictions.
The code seems to be longer because Ibrahim wanted to show you an additional API. It could be just two lines.

We really had some really complicated trees to support when we started to build the component. We simply had to build this tree first because not every tree can be easily written with a connect by SQL query. Sometimes many tables are involved and even some code to determine the child nodes. Hiding all the logic behind a view and using a connect by on this view was also not the best option for various reasons, including performance.

So we created a tree component that allows us to create trees of any complexity easily and render them fast.
When we were done, we asked ourselves: Do we want to add direct support for a connect by tree or is this good enough and we can move to other much needed features?

We compared the two ways and decided to move on to other features. Here was our reasoning: You usually have 1 at most 2 tree components in an application. They are usually complex enough that a simple connect by support is not good enough and you have to do more anyway. Besides, in cases where the tree is simple, saving a potential 30 minutes will not effect the total completion time of a project that lasts 1-2 months. So, the return on the investment was really small.

Our thought was that being able to do a tree with 11 clicks or having connect by support looks good in a demo but in real life where Formspider makes a difference, our tree shines. Try to build the tree component for the Airforce Recruiting System with just 11 clicks and you will want to throw yourself from the nearest building. :-)

So this was our reasoning back in the days. It served us well so far. These days the framework is a lot more mature though. Maybe it is time to add connect by support. :-)

2. XML Editor
Thanks. It really is one of the best in the market which makes writing XML a breeze. We really put a lot of work into it. It is nice to hear it being appreciated.

3. Wizards
There are two wizards. Right click a data source and you will see them. We intend to add more.

4. GUI Designer
We are working on a GUI Designer. It is pretty cool. Pretty much every web framework relies on a text based editor and have a crappy GUI Editor. We will not be one of them and create a beautiful GUI Designer that actually works.

The text definitions are necessary for source control. So XML editor is here to stay and this is something every Forms and Apex developer needs to get used to. Text is the only way we can integrate with world class source control systems like Git. (yes, we are working on a Git Formspider integration)

5. What we are competing with?
We are not really competing with anyone. We are just trying to create the best framework for PL/SQL developers. As PL/SQL developers, this is the framework we want to build applications with. We think it is much better than anything else out there in terms of its architecture. It may not have every feature you are looking for yet but that's because it is a new framework not because its incapable of doing things.

To see the difference between Apex and Formspider, just try to build a three level master detail screen using both products. This is how it would look like in Formsider: http://formspideronline.com/formspider/main.html?name=DemoMain#DemoThreeLevelMasterDetailGrids

I wrote a comparison article because I receive this question a lot. So here is a page and a blog post I wrote comparing Formspider vs. Apex.

Blog Post: http://theformspider.com/blog/2012/06/23/formspiderapex/
Comparison Page: http://theformspider.com/product.php?descid=FormspiderVSOracleApex

I am happy to hear that you are moving forward with the tutorials. We truly appreciate your feedback. It is invaluable. We really need developers like you give us honest feedback to steer the product. As you get to know Formspider, I am hopeful that it will grow on you. :-).It really has a great architecture.

Make no mistake, you will also run into its shortcomings. But you will see that these are not architectural limitations, just stuff we haven't gotten around to build yet. This framework went live last May. Give it a little time. :-)

Hi,
Many thanks for the honest feedback. Let me reply to several issues you have raised

1) Framework with correct architecture: Many thanks! :-). I think this is what matter most while using a framework. We put a lot of thought into it.

2) In Formspider conditional display is done via API's. We have many API's that you can use to show and hide UI components and Panels. If you can show me your screens I can show you how you'd design them in Formspider. It is very much like in Oracle Forms really.

3) The next version of Formspider (1.2) which we are going to release in the coming weeks has many interactive reports features in it. I think you are going to like them a lot. :-)

4) We started building our library with 2.2. But since then a lot has changed. We have rewritten many portions of it like the Grid component. We used components from other libraries such as JQuery. We are very happy with the performance of our library. And that's what is important. Not which version we started building our library with.