db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Levitt <de...@mylevita.com>
Subject Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
Date Tue, 12 Jul 2005 22:54:40 GMT
One addendum to that idea:

In the future, we could implement addition information
about the message such as a suggested user response
and a more detailed explanation of the error.  This
could also be stored in the comment for that message,
and then propogated to the DITA file generated from
the code.  So my example comment might be modified to
look like this:

// message metadata id="22015" 
// begin parameters
// p1="functionName" p2="typeName" p3="typeName"
p4="typeName" 
// end parameters 
// userresponse="This would be text of what the user
should do to correct the problem" 
// explanation="This would be more detailed
information about the error that might not be
appropriate to display for each time that error
occurs, but might be useful in the documentation for
that error." 
// end message metadata


--- Jeff Levitt <derby@mylevita.com> wrote:

> David, I've been thinking about your idea suggested
> fairly recently concerning generating the
> documentation page of the error messages from the
> code.  Would that complicate things too much if we
> combined that work with this effort?
> 
> My thought (and please let me know if this is
> something we should perhaps do later, after your
> proposal is implemented...) is that perhaps we can
> store metadata about a message in a comment within
> the
> code.  So for example, the string for message 22015
> might be stored in the code like this currently:
> 
> The %1 function is not allowed on the following set
> of
> types. First operand is of type %2. Second operand
> is
> of type %3. Third operand (start position) is of
> type
> '%4'.
> 
> So after that string, maybe we have a comment that
> looks like this:
> 
> // metadata message="22015" begin parameters
> p1="functionName" p2="typeName" p3="typeName"
> p4="typeName" end parameters
> 
> (note that I am not proposing this exact syntax for
> the comment, just showing the logic)
> 
> Thus, your DITA doc file generation script would be
> modified so that when it prints the message string
> to
> the dita file, if it comes to a "%x" parameter in
> the
> string, it searches the comment for the "px" value
> for
> that parameter and replaces the token with the
> value:
> 
> The '<functionName>' function is not allowed on the
> following set of types. First operand is of type
> '<typeName>'. Second operand is of type
> '<typeName>'.
> Third operand (start position) is of type
> '<typeName>'.
> 
> Is that kind of logic possible?  I think it might be
> easy to write some sort of script to make the
> one-time
> conversion of the existing messages in the doc to
> this
> code + comment layout, and then we could say that
> any
> new messages written by any contributors in the
> future
> must follow this procedure of identifying labels for
> their parameters in comments.
> 
> Thoughts?
> 
> 
> 
> 
> --- "David Van Couvering (JIRA)"
> <derby-dev@db.apache.org> wrote:
> 
> >     [
> >
>
http://issues.apache.org/jira/browse/DERBY-289?page=comments#action_12315632
> > ] 
> > 
> > David Van Couvering commented on DERBY-289:
> > -------------------------------------------
> > 
> > I would like to modify the network client to use
> > localized messages.
> > However, the right way to do this is using message
> > ids, and these
> > message ids probably should be based on SQL
> states,
> > just as with
> > the embedded code.  We should also take advantage
> of
> > the existing
> > infrastructure for properly loading and composing
> > message strings,
> > rather than build a duplicate infrastructure for
> the
> > client code.
> > 
> > As a first step towards fixing exception handling
> in
> > the client, I am
> > therefore planning on working on creating a common
> > package hierarchy 
> > that contains code that can be shared across
> client
> > and server code.
> > 
> > Here are the steps I am planning on taking.  Your
> > comments are most welcome.
> > 
> > - Create a new top-level directory under
> trunk/java
> > called "common".  All
> >   packages under this directory would have the
> > prefix org.apache.derby.common
> > 
> > - Refactor the existing service classes under
> > org.apache.derby.iapi.services
> >   and org.apache.derby.impl.services into common
> > code and engine-specific
> >   code.  I would do the minimum possible so that
> the
> > error and i18n
> >   services can move over to the common directory. 
> I
> > do not intend to move
> >   over other services even if they could be
> > considered common; I feel this
> >   work should be done only as needed.
> >   
> >   At first glance, the packages impacted by this
> > refactoring effort would be:
> >     org.apache.derby.iapi.services.Monitor
> >     org.apache.derby.impl.services.Monitor
> >     org.apache.derby.iapi.services.i18n
> >     org.apache.derby.iapi.error
> > 
> >   There may be other packages impacted due to
> > dependencies I have yet to
> >   discover.
> > 
> >   I have noticed that some of the code seems to
> have
> > some fairly strong
> >   ties to the engine environment.  I hope to solve
> > this by 
> >   splitting some classes into a generic superclass
> > in the common 
> >   hierarchy and a subclass in the engine
> hierarchy. 
> > 
> > 
> > - In terms of the build environment, the easy
> > approach, and the approach 
> >   that matches what already exists, would suggest
> > creating a new jar file, 
> >   derbyclient.jar.  
> > 
> >   However, we already have a large number of jar
> > files, and adding one 
> >   more I feel is going in the wrong direction.  I
> > would like to better 
> >   understand the motivation for having multiple
> jar
> > files when I think 
> >   we could do with two: one for engine/server-side
> > code and one for 
> >   client code, e.g.  
> > 
> >     derby.jar
> >     derbyclient.jar
> >     <locale_jar_files>
> > 
> >   Comments on this are most appreciated.
> > 
> >   Thanks,
> > 
> >   David
> > 
> > 
> > > Enable code sharing between Derby client and
> > engine
> > >
> >
> ---------------------------------------------------
> > >
> > >          Key: DERBY-289
> > >          URL:
> > http://issues.apache.org/jira/browse/DERBY-289
> > >      Project: Derby
> > >         Type: Improvement
> > >   Components: Network Client
> > >     Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2,
> > 10.1.1.0
> > >  Environment: N/A
> > >     Reporter: David Van Couvering
> > >     Priority: Minor
> > >      Fix For: 10.2.0.0
> > 
> > >
> > > Right now, there is no way for the Derby network
> > client to share code with the Derby engine.  We
> > should have a separate jar file, e.g.
> > derby_common.jar, that contains shared code and is
> > used by both the client and the engine.  
> > 
> 
=== message truncated ===


Mime
View raw message