db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
Date Wed, 13 Jul 2005 22:59:05 GMT
Hi, Jeff.  I like your ideas, I think there's something we can do here.
  I need to think about it further.  There are any number of ways we can
accomplish having a single source for the messages so that you can
generate DITA and the message properties file.  An XML file might be a
good approach.  This requires further thought.

That said, I agree with your thought that it probably belongs as a
separate task.  Would you be willing to create a JIRA item for this?

Thanks,

David

Jeff Levitt wrote:
> 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