On 2005-12-20, Cees Hek <[EMAIL PROTECTED]> wrote:
> On 12/20/05, Mark Stosberg <[EMAIL PROTECTED]> wrote:
>> On 2005-12-20, Michael Peters <[EMAIL PROTECTED]> wrote:
>> >
>> > I'm actually leaning toward Graham's idea here that it just be in the
>> > plugins. I
>> > like the API but I'm not sure it's something that should be in the core. I
>> > know
>> > configuration is something pretty basic that every framework should have,
>> > but I
>> > don't see C::A as a framework... more as a framework for building
>> > frameworks.
>>
>> In my v2 RFC I proposed a very minimum of code in the core:
>>
>> sub config { return undef }
>>
>> And that's just a convenience for plugin authors so they don't have to
>> check if the 'config' method exists, they can directly check
>>
>> $self->config('key_i_want');
>
> I want to create a standard logging API that plugins and users can use
> as well (with plugins that support Log::Dispatch, Log::Log4perl and
> simple print to STDERR plugins). Should we add stubs for those
> methods into the core as well?
This is consistent with the CGI::App's history and current design, which
consists of mostly empty space-- it mostly suggests a way to build your
applications. Truly the "frame" in "framework".
Since the 1.0 release over five years ago, web development has grown up.
Projects have gotten bigger and more complex as a norm. There are more
modules and layers involved and more abstraction. With this complexity
comes a greater need for standardization and cooperation of /all/
aspects to maintain sanity.
> Although 'config' is a pretty common requirement, I think it is a
> slippery slope adding a stub for it into the core.
I don't think so. We are experts building the future of CGI::Application
based on hind sight. It's not that we think we might need a standard
config() next year, we can how we could have used it last year.
To answer your question about logging-- Yes I think we should define a
mininum common logging API and possibly add a stub for it as well.
Since you are more involved in that aspect, I would welcome a proposal
for that aspect.
For other suggested additions I think we should continue to bring them
to the group for the discussion and be critical about what's essential
and how to best design it.
Here's the use case for a decent logging API:
Successful websites continue to be refined after they are in production.
To drive that refinement cycle it's critical to have good feedback about
what's workingand what isn't.
A well designed logging system can help you as a developer identify and
respond to key problems as they arise. It's so much nicer to find out
about bugs before a customer or end user reports them!
This is not only possible but easy with a logging system that allows to
flag some errors as critical and others as warning.
A tool like 'swatch' can complete the loop by monitoring your log files
and e-mail the dev team when critical errors come up.
http://www.spitzner.net/swatch.html
The role of CGI::App should to make it easy to include this 'best
practice' in your workflow. We can do that providing a standard,
minimal logging API, and let plugins do the heavy lifting.
Mark
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
