Not 100% sure this is appropriate here--mods, please delete if it
isn't.
I wanted to announce an ADF project I just started on SampleCode: A
completely rewritten framework for DB API-based ADF Business
Components. The first public beta version (0.1b) is available for
download now, but I'm especially interested in finding any community
members who might be interested in participating in the project--
either as beta testers (apply as an "Observer") or as developers
(apply as a "Developer")--there are a lot of expansions and
enhancements I think the framework could still stand. You can find it
at https://database-api-based-adf-bc.samplecode.oracle.com/ (you need
to log in with your Oracle SSO account; the same one you use for the
forums or to download JDeveloper).
The reason I think it *might* be relevant here is that it really
demonstrates what I've been pushing as part of the Extreme Reusability
methodology--the serious use of custom framework classes + custom
metadata as a way of avoiding per-component, and preferably even per-
application, Java code. This is a bit more in-depth than many
organizations might want to go to enable a single feature--I wanted to
preserve as much standard ADF functionality, and come as close to
standard ADF performance profiles, as I possibly could (and I want to
do still more in the future)--but this should give you an idea of just
how simple development of individual applications can be with a
reusable custom framework.
This is very inderesting.
i signed in and walked through the manual.
It seems realy good, yet i wander what is the scope of the project.
Is it just an easier way to implement procedure based entities?
The requirements that i have seen about this is to migrate oracle
Forms applications with procedure based blocks.
Yet in Forms applications the input parameters was of Table types, and
could handle more than one row in the same execution.
is this included in the scope of the project?
Generaly, when you create new applications what are the reasons that
can lead you to base BC on DB procedures and functions?
this could be a nice subject for discussion.
On Oct 27, 5:38 am, Avrom Roy-Faderman <av...@avromroyfaderman.com>
wrote:
> Not 100% sure this is appropriate here--mods, please delete if it
> isn't.
> I wanted to announce an ADF project I just started on SampleCode: A
> completely rewritten framework for DB API-based ADF Business
> Components. The first public beta version (0.1b) is available for
> download now, but I'm especially interested in finding any community
> members who might be interested in participating in the project--
> either as beta testers (apply as an "Observer") or as developers
> (apply as a "Developer")--there are a lot of expansions and
> enhancements I think the framework could still stand. You can find it
> athttps://database-api-based-adf-bc.samplecode.oracle.com/(you need
> to log in with your Oracle SSO account; the same one you use for the
> forums or to download JDeveloper).
> The reason I think it *might* be relevant here is that it really
> demonstrates what I've been pushing as part of the Extreme Reusability
> methodology--the serious use of custom framework classes + custom
> metadata as a way of avoiding per-component, and preferably even per-
> application, Java code. This is a bit more in-depth than many
> organizations might want to go to enable a single feature--I wanted to
> preserve as much standard ADF functionality, and come as close to
> standard ADF performance profiles, as I possibly could (and I want to
> do still more in the future)--but this should give you an idea of just
> how simple development of individual applications can be with a
> reusable custom framework.
Indeed very interesting topic. From my experience, same as Michael points,
its very important in Forms modernization to have some kind of standard
solution for existing PL/SQL procedure blocks reusability. In my opinion,
there are no too much use cases for completely new applications, when you
use PL/SQL blocks. However its really important in those projects where
existing Forms systems are modernized to Fusion (I guess majority of current
projects).
Andrejus
2009/10/31 Michael Koniotiakis <mko...@hotmail.com>
> This is very inderesting.
> i signed in and walked through the manual.
> It seems realy good, yet i wander what is the scope of the project.
> Is it just an easier way to implement procedure based entities?
> The requirements that i have seen about this is to migrate oracle
> Forms applications with procedure based blocks.
> Yet in Forms applications the input parameters was of Table types, and
> could handle more than one row in the same execution.
> is this included in the scope of the project?
> Generaly, when you create new applications what are the reasons that
> can lead you to base BC on DB procedures and functions?
> this could be a nice subject for discussion.
> On Oct 27, 5:38 am, Avrom Roy-Faderman <av...@avromroyfaderman.com>
> wrote:
> > Hi all,
> > Not 100% sure this is appropriate here--mods, please delete if it
> > isn't.
> > I wanted to announce an ADF project I just started on SampleCode: A
> > completely rewritten framework for DB API-based ADF Business
> > Components. The first public beta version (0.1b) is available for
> > download now, but I'm especially interested in finding any community
> > members who might be interested in participating in the project--
> > either as beta testers (apply as an "Observer") or as developers
> > (apply as a "Developer")--there are a lot of expansions and
> > enhancements I think the framework could still stand. You can find it
> > athttps://database-api-based-adf-bc.samplecode.oracle.com/(you need
> > to log in with your Oracle SSO account; the same one you use for the
> > forums or to download JDeveloper).
> > The reason I think it *might* be relevant here is that it really
> > demonstrates what I've been pushing as part of the Extreme Reusability
> > methodology--the serious use of custom framework classes + custom
> > metadata as a way of avoiding per-component, and preferably even per-
> > application, Java code. This is a bit more in-depth than many
> > organizations might want to go to enable a single feature--I wanted to
> > preserve as much standard ADF functionality, and come as close to
> > standard ADF performance profiles, as I possibly could (and I want to
> > do still more in the future)--but this should give you an idea of just
> > how simple development of individual applications can be with a
> > reusable custom framework.
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> Indeed very interesting topic. From my experience, same as Michael points,
> its very important in Forms modernization to have some kind of standard
> solution for existing PL/SQL procedure blocks reusability. In my opinion,
> there are no too much use cases for completely new applications, when you
> use PL/SQL blocks. However its really important in those projects where
> existing Forms systems are modernized to Fusion (I guess majority of current
> projects).
> Andrejus
> 2009/10/31 Michael Koniotiakis <mko...@hotmail.com>
> This is very inderesting.
>> i signed in and walked through the manual.
>> It seems realy good, yet i wander what is the scope of the project.
>> Is it just an easier way to implement procedure based entities?
>> The requirements that i have seen about this is to migrate oracle
>> Forms applications with procedure based blocks.
>> Yet in Forms applications the input parameters was of Table types, and
>> could handle more than one row in the same execution.
>> is this included in the scope of the project?
>> Generaly, when you create new applications what are the reasons that
>> can lead you to base BC on DB procedures and functions?
>> this could be a nice subject for discussion.
>> On Oct 27, 5:38 am, Avrom Roy-Faderman <av...@avromroyfaderman.com>
>> wrote:
>> > Hi all,
>> > Not 100% sure this is appropriate here--mods, please delete if it
>> > isn't.
>> > I wanted to announce an ADF project I just started on SampleCode: A
>> > completely rewritten framework for DB API-based ADF Business
>> > Components. The first public beta version (0.1b) is available for
>> > download now, but I'm especially interested in finding any community
>> > members who might be interested in participating in the project--
>> > either as beta testers (apply as an "Observer") or as developers
>> > (apply as a "Developer")--there are a lot of expansions and
>> > enhancements I think the framework could still stand. You can find it
>> > athttps://database-api-based-adf-bc.samplecode.oracle.com/(you need
>> > to log in with your Oracle SSO account; the same one you use for the
>> > forums or to download JDeveloper).
>> > The reason I think it *might* be relevant here is that it really
>> > demonstrates what I've been pushing as part of the Extreme Reusability
>> > methodology--the serious use of custom framework classes + custom
>> > metadata as a way of avoiding per-component, and preferably even per-
>> > application, Java code. This is a bit more in-depth than many
>> > organizations might want to go to enable a single feature--I wanted to
>> > preserve as much standard ADF functionality, and come as close to
>> > standard ADF performance profiles, as I possibly could (and I want to
>> > do still more in the future)--but this should give you an idea of just
>> > how simple development of individual applications can be with a
>> > reusable custom framework.
>> --
>> You received this message because you are subscribed to the ADF Enterprise
>> Methodology Group (http://groups.google.com/group/adf-methodology). To
>> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
Thanks for the replies. I agree that the ability to post table types
would be useful...but I think it would be pretty hard to do at the
entity object level, at least alone. You might get entity objects to
add themselves (during their DML operations) to some table-like
structure at the transaction level (as opposed to posting directly),
and then override Transaction.postChanges to, at the end, pass these
table-like structures into the appropriate procedures. Or maybe
something with DML batching? Not quite sure. At any rate, please file
it as an ER, although it will probably be a "post-1.0" thing.
I also agree that this is *mostly* useful for modernizing existing
apps. I am familiar with a copule of other use cases, though. One
relates to extreme reusability. Even if you're creating a new
application, there's still a substantial chance you're doing so in a
shop where PL/SQL is a much more common skill than Java. For an
application with a lot of business logic, the shop will be more
productive if the PL/SQL coders can stay in their comfort zones and
write packages in the database to implement the business logic. For
simple validation, this can be done with triggers, but for more
complex business logic, it may be useful to have a standalone
procedure.
The last use case relates not to entity objects but to view objects.
Sometimes you'll need to populate a view object in such a way that
using a table or view would be extremely difficult. Here's an example:
In the database (and used by lots of other code), you have three
tables of hour ranges: OPERATING_HOURS, CLINIC_HOURS, and
CALL_NURSE_HOURS. Each table has the columns ID (the PK), PROGRAM_ID
(the FK), START_TIME, STOP_TIME and DAY_OF_WEEK. With me so far?
OK, there's a business rule in place (let's not worry about enforcing
it yet--just take it for granted) that no hours of the same type for
the same program on the same day can overlap, and another that there
can only be (at most) three sets of hours of the same type for the
same program on the same day (although there might be less--even
zero). Now, here's our UI requirements:
We need to be able to plug in a PROGRAM_ID (e.g., through a view link
with the PROGRAMS table), and get a table with the following columns:
DayOfWeek, IntervalNumber (1-3 for each DayOfWeek),
OperatingHoursStart, OperatingHoursStop, ClinicHoursStart,
ClinicHoursStop, CallNurseHoursStart, CallNurseHoursStop. The times
within each day (of each type) needed to be sorted with the earliest
StartTime first.
That's pretty easy to do in a PL/SQL stored procedure, but *really*
hard to do with a SQL view--getting the various rows of the subqueries
(including "null rows" in cases where, say, a program has only one
CLINIC_HOURS interval on a particular day) to line up is an intense
challenge.
This is just intended as an example--there are of course many cases
like this.
I will be interested to be part of it( but only after Jan 20th i will be
able to start spending time towards that), my current project goes live on
Jan 4th and expecting to be busy two weeks of go live support.
On Mon, Nov 9, 2009 at 6:20 PM, Avrom Roy-Faderman <
> This project is looking for someone to take it over after release 1.0.
> Anyone interested?
> Thanks much,
> Avrom
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> This project is looking for someone to take it over after release 1.0.
> Anyone interested?
> Thanks much,
> Avrom
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
Go to the following link and apply as a developer (I'll approve you). Go
ahead and check the projects out of Subversion. If you haven't read the
developer's guide, start with that, and then start looking through the
source code. When you feel like you've got a general sense of what's going
on, let me know again and we'll talk about next steps.
> I'm interested to work as a developer on this project.
> Thanks,
> Nirav Shah
> On Mon, Nov 9, 2009 at 7:20 PM, Avrom Roy-Faderman <
> av...@avromroyfaderman.com> wrote:
>> Hi all,
>> This project is looking for someone to take it over after release 1.0.
>> Anyone interested?
>> Thanks much,
>> Avrom
>> --
>> You received this message because you are subscribed to the ADF
>> Enterprise
>> Methodology Group (http://groups.google.com/group/adf-methodology). To
>> unsubscribe send email to
>> adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com
> Go to the following link and apply as a developer (I'll approve you). Go
> ahead and check the projects out of Subversion. If you haven't read the
> developer's guide, start with that, and then start looking through the
> source code. When you feel like you've got a general sense of what's going
> on, let me know again and we'll talk about next steps.
> > I'm interested to work as a developer on this project.
> > Thanks,
> > Nirav Shah
> > On Mon, Nov 9, 2009 at 7:20 PM, Avrom Roy-Faderman <
> > av...@avromroyfaderman.com> wrote:
> >> Hi all,
> >> This project is looking for someone to take it over after release 1.0.
> >> Anyone interested?
> >> Thanks much,
> >> Avrom
> >> --
> >> You received this message because you are subscribed to the ADF
> >> Enterprise
> >> Methodology Group (http://groups.google.com/group/adf-methodology). To
> >> unsubscribe send email to
> >> adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> <adf-methodology%2Bunsubscribe@googlegroups.com<adf-methodology%252Bunsubsc ribe@googlegroups.com>
> > --
> > You received this message because you are subscribed to the ADF
> Enterprise
> > Methodology Group (http://groups.google.com/group/adf-methodology). To
> > unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodology+unsubscribe@googlegroups.com<adf-methodology%2Bunsubscribe@ googlegroups.com>
|
