Re: update a 200 - 300 row table - APEX
Date: Tue, 9 Jun 2009 07:36:00 +0200
There will probably be some answers from the APEX experts, but I'll give my view on it.
You can build applications that are hard and easy to maintain. It is a very similar model to Forms where you can put all kinds of triggers and database logic in the form, or you can separate it to only have the user-interface in forms.
I would consider the same things for APEX. Break out business logic to separate packages, possible the SQL in its own packages and keep only the user-interface logic in APEX. This is a general best practice (for all development models, not specifically for APEX) as the user interface typically is changed more often than the data structures or business logic.
That way you would not end up with code pieces buried in different places in APEX, only what is needed to make the application display the way you want.
On Tue, Jun 9, 2009 at 5:52 AM, Tony Adolph <tony.adolph.dba_at_gmail.com>wrote:
> Hi Maxim and APEXers the list,
> I got APEX 3.2 up and running using the Embedded pl/sql Gateway with
> 10.2.0.4 running on VMware guest Suse 10.1 and MS Windows Server 2003,...
> thanks to your help
> I've now read (most of) the 2 day development guide that comes with the
> build and have produced a simple prototype. I have a few changes that I
> need to make after a demo, but both client and I are happy. Nice one :-)
> Very impressive.
> My app was *very* simple, and therefore straightforward. But with such a
> powerful tool I can envisage creating a bird's nest of an application that
> works a treat and is *totally* understandable and maintainable at
> development time, but a few weeks/months down the road is a bit of a
> I wonder how complicated a "simple" app would have to be before
> maintenance became a nightmare.
> How are these APEX applications designed from scratch, especially when the
> app is expected not to be trivial. And once designed, how is that design