Results 1 to 4 of 4

Thread: Model super class & communication factories

Hybrid View

  1. #1
    Join Date
    Oct 2005
    Location
    Urmond, Netherlands
    Posts
    51
    Rep Power
    10

    Lightbulb Model super class & communication factories

    I was looking at the mvc architecture used in the Zimbra client. Very nice, by the way, that the architecture can also be used for client side javascript, I hadn't thought about that. I noticest that the model objects generate their own parameter xml-structure for the soap requests that are send to the server. I was thinking that it must take a lot of development time to create those methods and a lot of maintenance time to change it when something changes in the model. This isn't a problem for one model but if you use multiple models this could get anoying .

    I had the idea to create a parent Model class. Al classes that are inherited from this class must represent the models (or structs) that are send to the server via the SOAP request. Or they must at least be capable to give back an object structure that can represent the models that you send with SOAP requests. The parent Model class would have the methods to accomplish this. The only thing that needs to be defined in the child models is the structure definition and this could be a simple array.

    The models must not give back the xml structure them selves. They would become to dependend on the way that is communicated. We would use a factory pattern to solve this problem. A 'Communication' factory could create an object that can read the structure definition of a model class. This object would take or get al the values from the model and create an xml (or what you need) structure so that it can be send to the server. This way you could implement SOAP1.1, SOAP1.2, XML-RPC and other communication protocols without changing anything on the server. Also the development time on the models will be a lot shorter because you don't have to write so much code all the time.

    But maybe my idea sucks because it would take javascript to much time to communicatie with the server .

    What do you guys think about my idea? (Maybe you already thought about it and it has to much negative effects. But then I would be glad if you would share them with rest and me).

    Soon I am going to try to implement a prototype version of the idea, to see if it works.

  2. #2
    Join Date
    Oct 2005
    Location
    Urmond, Netherlands
    Posts
    51
    Rep Power
    10

    Default No one?

    Does no one have a oppinion about my idea ? Or is my explanation not clear or to long? I nag about this because I am really interrested about what you guys (or girls) think.

  3. #3
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    In general we are very busy right now trying to close out the next release. So sorry if we skip the longer far out thinking posts. We are very finish line driven the last week or so.

    My $0.02 is our SOAP is pretty simple and our server doesn't change much where we *have* to update the client. So for our uses this would be an overkill and one more level of indirection. Of course we know the SOAP API pretty well since we work with it so offten so I can see how an outsider amy think that creating all the SOAP by hand is tedious. So I don't think this is a bad idea, but it's not something that we can't live without.

    If you think it's something that would be usful for you then by all means try it. If it proves general enough we'll take a look.

  4. #4
    Join Date
    Oct 2005
    Location
    Urmond, Netherlands
    Posts
    51
    Rep Power
    10

    Default

    Thanks you took the time to think about my idea. I will shut up with the think questions, till the next release .

    I will implement the idea and then we will see if it usefull.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •