What I read here gives me hope, that it will go on since a lot of people really do care about the future of APEX.
Thank you to all of you!
Even if I may be treated as an babbler... (I also wrote about this topic in another thread)
And even in full awareness that one or another don't want to hear it anymore:
A really user friendly calendar (just call it „interactive calendar„) is needed also.
Most people know outlook or similar products and the are common with it
and like there functionality just because the a familiar with it.
They simple expect to find something similar in an APEX application too when it comes to calendar topics.
I'm not new to Oracle and PL/SQL but I'm a greenhorn with APEX (surely you can see this from the questions I asked so far...) but finally I managed to spent time and effort on it.
You may believe me or not but every single use case Ii can imagine would need a calendar part as a GUI-component.
And that not only to view something but also to enter into a calendar (in a simple and userfriendly way).
So please take this onto your feature request list too - preferentially at the most upper rank you can :-)
Thank you and kind Regards
Yes I do think calendar's are important, behind forms, reports, and charts, I think calendar's are the 4th application building block. I am also hopeful that we will see a Calendar plug-ins so we can get improved calendar support in APEX 4.0. Region plug-ins allow APEX experts to extend APEX, and these extensions could be calendars. So look out for them.
Thanks for the input its been very useful. Just a quick question, could you tell me if there is a user guide available for websheets like there is for the application builder? I've been through the Oracle by Example exercise but I'm looking for something that goes into a bit more detail about the various features. The only reference I could find was a couple of paragraphs in the Application builder User Guide explaining the difference between a Database application and a Websheet application.
Because WebSheets are pointed more at end users than Developers, we did not produce a User's Manual. There is some help when you create one or edit the properties within the App Builder (to explain the application-level attributes). With a WebSheet app running, click the Help button in the upper right and you will get a few tabs:
<li>About - your app, shows stats and the description if one is entered</li>
<li>Overview - an overview of WebSheets (pages, data grids, annotations, ...)</li>
<li>Access Control - showing who can do what given the authentication scheme used and the user's role</li>
<li>Markup Syntax - explanations and examples of the tags you can use</li>
<li>Application Content - shows your pages, sections, files, data grids to help while adding markup syntax
<li>FAQ - things we thought you might ask</li></li>
Hope these help -
Websheet > Application Properties > Style (subheading) > Page Style?
When I click the label to get the help for this option it says "No help exists for this item".
I've tried the different options and cant work out what it does.
A user guide would be really useful because if this doesnt make sense to somebody that uses Apex every day, how is an end user supposed to understand?
I will add a bug to include the missing help - that is one item that got missed. There is an obe about building that might be helpful too - http://st-curriculum.oracle.com/obe/db/apex/r40/websheets/websheets_ll.htm
Ah right I see.
So what is the option supposed to do? Is it supposed to change the look and feel?
I have tried the available options and none of them seem to make any difference to my websheets app?
In response to Andre's Question. Is there a way to add a calendar to a Websheet Application.
The usage of the calendar could be anything from a consensus building plan on let's say sales numbers to as simple as a leave planner.
Appreciate your response on this.
Going back to one of the questions in my original post. If people wouldn't mind sharing I'd be very interested to know what sort of things Websheets are being used for or what you are intending to use them for?
The Oracle By Example suggests websheets could be used to create a task list kind of application which I could see as a valid business use, the sample application provided is a wiki of Big Cats??? (oracle - not sure where you're going with this one, maybe useful for a zoo or an extreme pet shop?? :-S)
After playing with the technology for a while I'm thinking perhaps it could be used as a basic global contacts list (telephone number, address etc), or maybe as a basic company intranet.
Does anybody else have any ideas?
So what can you use websheets for? Answer 3 primary use cases: Use case 1) Project Wiki / Project website
Create a websheet for a given project (Project X), deploy application to Project X team members, with some combination of read only and read write access
Start building pages, for example "Welcome to project X, Bill will be managing [[UI Design]], Sue will manage the [[data model]], and Sam will be creating [[page flow diagrams]].
** note each of the [[abc]] will be expanded into child pages. On first creating they will be red, you then click on the links and create the new pages. You then add content to the new pages, in this example Bill would be the primary author of his pages etc.
*Use Case 2) Online Data Management (share data on the web)*
Create a websheet application and any number of "Data Grids". Data grids are elegantly updatable reports, with lots of functionality including annotations and validations. This will allow you to manage data that you may do in excel (not a replacement for all use cases of spreadsheets, mostly data collection use cases; such as project tracking). Note all changes are tracked and reported, so you can see who changed what when. You can integrate reports and charts of this data in your "wiki" pages using the create section wizard.
*Use Case 3) Reports on Database Data (expose online interactive reports on database data linked from web pages)*
Expose interactive reports on data stored in tables in your Oracle database, provide users access to these reports. For example you may have some data that summarizes your latest test results, and you can expose this. To do this (1) create a report from the "data" tab, using sql such as "select * from test1", then create a link to this report from a wiki like page using syntax: "Please review [[report: test1]] data and see if it looks good.". You can also add SQL results, such as "here is something interesting [[SQL: select test_name, test_results, value1, value2 from test1 where value1 > 10 and value2 < 13]].
** note SQL tags and reports are not enabled by default for security reasons, to enable SQL reports and SQL tags, (1) navigate the apex application builder, (2) click on your websheet application, (3) click on "edit properties", (4) set "enable SQL access" to "Yes".
However the real use case is the combination of all of these use cases into one. The uses cases are informal, and it is expected that the websheet application would be maintained by most users of the websheet (e.g. community managed). This is in contrast to a typical APEX application that is developed by a developer and deployed to users. With websheets users and developers are one and the same (like wikipedia) but with SQL.
"This is in contrast to a typical APEX application that is developed by a developer and deployed to users. With websheets users and developers are one and the same (like wikipedia) but with SQL."
My place of work, a government entity, was looking into using Websheets for reporting performance measures online and to the public. The hope would be that Websheets would be so user-friendly and simple that each department could have non-IT staff manage their pages on the application (generally consisting only of text and a graph or two per page). Then we could publish the resulting application to the public, who could see, but not edit the information. We currently use Apex to generate a performance measure application, but hit a bottle neck with all the major editing needing to go through IT. I feel like your last two sentences mean that our idea to publish or deploy Websheets to end users isn't a good fit with the Websheets intention to have developers and end users being one in the same. Am I interpreting that correctly?