Multiple Descriptors
Locked
 
|
In trying to create more modularity in my application. I'm wanting to create a descriptor specific for each module. When building an application, I would like to pull in the "modules" and then have Glorp accept all of the descriptors when setting up the RDBMS access.
Is this possible with the current framework?
Brad Selfridge
|
|
|
I'm not completely clear about your setup, but if each module has descriptors for different tables, without overlap (including links to other tables), then it seems possible to separate your descriptors into separate modules, and have "larger" modules that import the descriptors they need. Is that what you have in mind? I guess a fancy way to say this is that your modules would need to "cover" the transitive closure of the tables they are concerned with, and these closures shouldn't overlap between modules. Of course, it's Monday morning, so I could be completely off base on your question.
Dave Wallen Developer Cincom System 3375 Scott Blvd. Suite 420 Santa Clara, CA 95054 office website 513-612-2003 http://www.cincomsmalltalk.com --- CONFIDENTIALITY STATEMENT --- This e-mail transmission contains information that is intended to be privileged and confidential. It is intended only for the addressee named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited, please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Brad Selfridge Sent: Monday, May 23, 2016 9:13 AM To: [hidden email] Subject: Multiple Descriptors In trying to create more modularity in my application. I'm wanting to create a descriptor specific for each module. When building an application, I would like to pull in the "modules" and then have Glorp accept all of the descriptors when setting up the RDBMS access. Is this possible with the current framework? ----- Brad Selfridge -- View this message in context: http://forum.world.st/Multiple-Descriptors-tp4896877.html Sent from the GLORP mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/glorp-group. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/glorp-group. For more options, visit https://groups.google.com/d/optout. |
|
|
In general the idea is that you can put the descriptors into the system however you like. There's a simple default mechanism where they're all on the system and it uses a naming convention to find the methods, but it doesn't have to work that way. It can also handle having them as class methods, which some people like, or in general adding them any way you'd like. OK, maybe not quite so simple, because in order to register descriptor A it may need to be able to find descriptor B, and my memory is fuzzy on where exactly that has to happen. But it should be very possible. On Mon, May 23, 2016 at 11:10 AM Wallen, David <[hidden email]> wrote: I'm not completely clear about your setup, but if each module has descriptors for different tables, without overlap (including links to other tables), then it seems possible to separate your descriptors into separate modules, and have "larger" modules that import the descriptors they need. Is that what you have in mind? I guess a fancy way to say this is that your modules would need to "cover" the transitive closure of the tables they are concerned with, and these closures shouldn't overlap between modules. Of course, it's Monday morning, so I could be completely off base on your question. You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/glorp-group. For more options, visit https://groups.google.com/d/optout. |
|
|
In my quest to interject a more modular approach to having multiple DescriptorSystem(s), I ran across the "DynamicDescriptorSystem" class. I thought about using this class, but didn't know the business case for it. Can someone explain what purpose this class was meant to be?
Brad Selfridge
|
|
|
So, if you look at DescriptorSystem, what happens is that it constructs the list of all classes, all tables, and all descriptors. e.g. allClasses calls constructAllClasses, whose default implementation is constructClassesFromDescriptorMethods. So it looks for all the methods whose naming convention looks like they're descriptors, and finds the classes, and adds that to the list of classes. If you want it to do something else, override constructAllClasses. Various tests descriptor systems hard-code that list. DynamicDescriptorSystem expects the user to explicitly add the classes. The comment about identity and ordering means that descriptor systems rely on identity. Any time it asks for the classModel, descriptor, or table, it had better get back the identical one or bad things will happen. So if you're populating the system yourself you need to make sure that before a class is used, it's been added, and similarly for tables and descriptors. In practice that means that you probably want to add all of them empty and then populate them. Otherwise, as soon as you add the descriptor it will expect to be able to access the corresponding class model, and so on. You can look at the users of DynamicDescriptorSystem to see what they're doing. But possibly a better model would be the StoreDescriptorSystem in VisualWorks, where there are subclasses for different versions, which add tables and fields. Or just implement a class that adds the tables/classes/descriptors however you want. On Wed, Jun 1, 2016 at 1:38 PM Brad Selfridge <[hidden email]> wrote: In my quest to interject a more modular approach to having multiple You received this message because you are subscribed to the Google Groups "glorp-group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. To post to this group, send email to [hidden email]. Visit this group at https://groups.google.com/group/glorp-group. For more options, visit https://groups.google.com/d/optout. |
«
Return to GLORP
|
1 view|%1 views
| Free forum by Nabble | Edit this page |