[forge-dev] Data access logic used by scaffold code

[Dan Allen]

On Tue, Jan 24, 2012 at 02:15, Lincoln Baxter, III
<lincolnbaxter at gmail.com>wrote:

> On Tue, Jan 24, 2012 at 1:59 AM, Dan Allen <dan.j.allen at gmail.com> wrote:
>
>> On Tue, Jan 24, 2012 at 01:27, Jason Porter <lightguard.jp at gmail.com>wrote:
>>
>>>
>>> As for the non dep idea, I can certainly understand where Lincoln and
>>> Pete are coming from.
>>
>>
>> I don't.
>>
>
> This is a support-driven requirement. There was a good deal of concern as
> to what kind of libraries we wanted to "commit" to for a 5-7 year support
> plan. This is why Seam and the other libraries were removed.
>

Again, I can stand see the point being made standing in those shoes.

You do have to admit that it looks a bit bipolar that we are working hard
to grow a CDI ecosystem with one face, then telling developers they don't
need it (and we don't want to support it) with another face.

When did we become so fearful of supporting open source software, whether
it's invented "here" or not. I'm not saying your wrong, I'm just
encouraging you to take another look.


>
>
>> I do wonder though if that would preclude us from creating a CDI
>>> extension for rolling our own simple CRUD framework
>>
>>
>> The one reasonable path I see here is working out the framework and then
>> having Forge just spit it out into the project. (I know that will turn
>> Richard's stomach). But then, it's easy to nuke that package and add the
>> dep...likely update the imports to use the right package too. In fact,
>> *that* could be a Forge plugin. It would be called
>>
>
> There are always multiple paths, just like we can always have multiple
> scaffold providers.
>

Agreed. We want to avoid the paradox of choice, but 2 - 3 strong options is
fair.


> Open to extension - We can't, and I would argue that we shouldn't, drop
> the pure EE scaffold, but we can certainly add more, and enhance the way in
> which plugins can inter-operate with the generated scaffold.
>

Can we agree to at least try to move some of the boilerplate into an
embedded framework rather than have the common logic duplicated in each
view bean? Does that fit within the requirements. After all, we want to
make sure the code is as maintainable as possible given these constraints.


> That's the area where I think we should be focusing, instead of thinking
> "straight up replacement." What we have is a good foundation. Let's build
> onto it, not bulldoze and rebuild it :)
>

I'm not suggesting bulldoze. Simply refactor a small portion.


>
>
>>
>> forge> leave-javaee-purist-mode
>>
>
> Also remember that what Richard has done with purist java EE is very
> impressive!
>

+100

Perhaps I should have started with "I was noticeably impressed during my
demo last week at the JBUG when I first saw the sophistication of the UI
forms and use of conversations." It's looking great.


> The main thing that's missing is security, and that's something that's
> just not there in EE. (And wasn't a requirement for the scaffold.)
>

<sarcasm> Yeah, because security one of those nice to have extras.
</sarcasm>

Sarcasm aside, I understand that this is just a general problem. Being
reminded of that, Jason and I recognized we should raise this as an early
task in DeltaSpike, perhaps integrating with another Apache library to
start, Shiro. Anyway, OT.

-Dan

-- 
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://google.com/profiles/dan.j.allen
http://mojavelinux.com
http://mojavelinux.com/seaminaction
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120124/95ac2c70/attachment.html