1 2 Previous Next 28 Replies Latest reply on Jun 5, 2012 2:06 PM by rbattenfeld Go to original post
      • 15. Re: SHRINKDESC-21 Prototyping - Read-only Views
        rbattenfeld

        Hi Andrew

         

        I had to the extend the POC because I am not sure how references to sub nodes have to be implemented regarding the mutable <-> inmutable transition. So, we have:

         

        • ApplicationDescriptorBase, ApplicationDescriptor, ApplicationDescriptorMutable
        • ModuleTypeBase, ModuleType, ModuleTypeMutable
        • WebTypeBase, WebType, WebTypeMutable

         

        According the schema, the hirarchy is ApplicationDescriptor->ModuleType->WebType

         

        The current problem I have is in ModuleTypeMutable the getWeb(); declaration. Eclipse suggests this:

        public WebTypeBase<? extends WebTypeBase<?, PARENTTYPE>, ModuleTypeBase<ModuleTypeMutable<PARENTTYPE>, PARENTTYPE>> getWeb();

         

        Which is a immutable view but a not mutable.

         

        The changes I made to your POC:

        • The sub nodes must be descriptor free that is the reason for example ModuleTypeMutable<PARENTTYPE>. Each element is a reusable node.
        • The sun elements of the root element , for example ApplicationType, is directly pasted in the descriptor for simplicity (as the current descriptor do as well)

         

        You can find the extended POC in: https://github.com/rbattenfeld/descriptors/tree/SD-21

         

        Let me know, what you think.

         

        Thanks,

        Ralf

        • 16. Re: SHRINKDESC-21 Prototyping - Read-only Views
          alrubinger

          Dan, Jason, Ralf:

           

          The reason I'd opted for "Mutable" in the middle of the class name is because of auto-completion.  Assuming the user knows he wants some type of "WebApp*Descriptor", he/she will start typing "WebApp"...

           

          To put "Mutable" first assumes that the user's first thought will be that he/she wants a mutable object first, then of a certain type as the second criteria, and the list of class names beginning in "Mutable" by alphabetical order will be very long.

           

          So while I agree about the natural readability of the names as Dan has suggested, I think the reasons above make a stronger case for "Mutable" to be in the middle of the class name.  Considering this, WDYT?

           

          S,

          ALR

          • 17. Re: SHRINKDESC-21 Prototyping - Read-only Views
            alrubinger

            In light of the deep-copy ops done to preserve immutability, this actually is a conversion and new Node model under the hood.  Does that change your opinion of "to" vs. "as"?

             

            S,
            ALR

            • 18. Re: SHRINKDESC-21 Prototyping - Read-only Views
              alrubinger

              Yes agreed, this is going to be tackled by:  https://issues.jboss.org/browse/SHRINKDESC-116

               

              ...but I've left it out-of-scope for this SD-21 prototyping to keep the concerns separate.

               

              S,

              ALR

              • 19. Re: SHRINKDESC-21 Prototyping - Read-only Views
                alrubinger

                Oh and please leave a comment with your thoughts on SD-116 or open a new Thread and link it back to the issue?  That way we'll ensure your suggestions don't get lost in the mix.

                 

                S,

                ALR

                • 20. Re: SHRINKDESC-21 Prototyping - Read-only Views
                  alrubinger

                  Hmm, it's really tough for me to see the changes you've made here, as they've been merged into the same commit with my POC.

                   

                  Do you need some Git help in getting a branch which builds atop of mine, adding commits above it?  If it's helpful, I can push my POC onto upstream/SHRINKDESC-21, rebase it atop upstream/master, and then you can lay your work atop that.

                   

                  S,

                  ALR

                  • 21. Re: SHRINKDESC-21 Prototyping - Read-only Views
                    dan.j.allen

                    Andrew Rubinger wrote:

                     

                    Dan, Jason, Ralf:

                     

                    The reason I'd opted for "Mutable" in the middle of the class name is because of auto-completion.  Assuming the user knows he wants some type of "WebApp*Descriptor", he/she will start typing "WebApp"...

                     

                    To put "Mutable" first assumes that the user's first thought will be that he/she wants a mutable object first, then of a certain type as the second criteria, and the list of class names beginning in "Mutable" by alphabetical order will be very long.

                     

                    So while I agree about the natural readability of the names as Dan has suggested, I think the reasons above make a stronger case for "Mutable" to be in the middle of the class name.  Considering this, WDYT?

                     

                    I don't agree. Perhaps for a developer brand new to ShrinkWrap Descriptors, they may not realize that there are Mutable versions of the descriptors, but this is a very minor concept to grasp. From then on out, they will be perfectly comfortable typing Mutable + <CTRL+Space> to get to the class they need. After all, they are using this type because they want to use the mutable version, so the term "mutable" must be at the forefront of their mind.

                    • 22. Re: SHRINKDESC-21 Prototyping - Read-only Views
                      rbattenfeld

                      I don't wanted to change or add the POC. I just realized that a key feature is missing POC.

                       

                      After spending some work with POC, the following is not clear to me:

                      • Handling of nested sub elements in the mutable and unmutable views
                      • The FilterType in the POC is directly coupled to the WebAppDescriptor, which is an issue. The FilterType is not the root element and must be as all other non-root elements reusable. In case of the FilterType, the WebFragmentDescriptor is using the FilterType as nested element, for example. 

                       

                      Can we extend the POC showing how to solve the two issues I am mentioning above? That would be great.

                       

                      Cheers,

                      Ralf

                      • 23. Re: SHRINKDESC-21 Prototyping - Read-only Views
                        alrubinger

                        Ah, sure.  I'm certain that the POC is a bit incomplete, so for any issues you need resolving I'll absolutely update.

                         

                        Will ping back to this forum when I can look deeper into the issues you describe; will be aiming to schedule it in for this week.  I'll likely need to catch you in IRC to understand fully what you're asking with regards to the nested sub-elements.

                         

                        That said, I do have a question:

                         

                        1) Why must FilterType be reusable?  We can't have two FilterTypes, in different packages, for WebAppDescriptor and WebFragmentDescriptor?  Is there any use case where these objects would actually be reused one descriptor to the next?

                         

                        I want to be clear we fully understand the requirements of the domain before proceeding.  Can't be making up reqs where they may not exist and make stuff tougher for ourselves.

                         

                        S,

                        ALR

                        • 24. Re: SHRINKDESC-21 Prototyping - Read-only Views
                          alrubinger

                          Twitter overwhelmingly backs you guys on this.  

                           

                          https://twitter.com/#!/ALRubinger/status/196833107872190464

                           

                          So "Mutable" will prefix the type name.

                           

                          S,

                          ALR

                          • 25. Re: SHRINKDESC-21 Prototyping - Read-only Views
                            rbattenfeld

                            A generation approach is almost impossible when the underlying model is not respected. In case of the java EE spec, all elements are modeled as complex types allowing to be referenced by other complex types. The designer of the spec already did a good job isolating reusable types referenced by other specs in dedicated, see javaee6.xsd. This is an example of referenced types by other specs but you will find reusable within the same spec. So, we have:

                            • Element A -> Element B -> Element C -> Element D or
                            • Element A -> Element C
                            • Element A -> Element D
                            • Element B -> Element D
                            • Element C -> Element B

                             

                            I don't specify in the scenario in which spec the elements are defined. They can be defined all in the same spec or defined in separate specs.

                             

                            Please have a look at the test cases:

                            • org.jboss.shrinkwrap.descriptor.test.jbossweb60.JbossWebDescriptorTestCase
                            • org.jboss.shrinkwrap.descriptor.test.ejbjar31.EjbJarDescriptorTestCase

                             

                            You will easily identify elements reused in many, many places. This is the fundamental approach in the current 'generated' descriptors. I am aware that the first descriptors didn't follow this.

                            • 26. Re: SHRINKDESC-21 Prototyping - Read-only Views
                              alrubinger

                              Ah, correct.  The top-level XSDs are referencing out to common XSDs, and the generation must take the same tack.  I'm following.

                               

                              OK, will tackle the POC with this in mind to see what can be done.

                               

                              S,
                              ALR

                              • 27. Re: SHRINKDESC-21 Prototyping - Read-only Views
                                rbattenfeld

                                I tried to sync myself after some time. I need more time than just 5 minutes:-)

                                 

                                Did you work on this further?

                                 

                                Regards,

                                Ralf

                                • 28. Re: SHRINKDESC-21 Prototyping - Read-only Views
                                  rbattenfeld

                                  Hi Andrew

                                   

                                  I pushed my little and trivial POC  to here: https://github.com/rbattenfeld/descriptors/tree/SD-21-poc

                                   

                                  Please don't be afraid that this POC is different from yours. I was simply not able to solve the generic issues I had. I tried do come from another angle. Perhaps we can mix things or you see what I wanted to solve. Furthermore, I realized that the long names for the generic types confused my totally. I was not able to read what is going on when a definition is spread over two lines. That is the reason why I used P type for Parent.

                                   

                                  I tried to make it as simple as possible. The idea is that there are always two interfaces for a certain descriptor, for the root lement and as well for all sub elements. They now by definition the counter part, immutable or mutable and can simply return the counter part. I didn't implemented the corresponding implementation classes. So, it is still questionable:-) My idea is that there is just one implementation class which implements both interfaces. A transition from mutable to immutable is just returning the same instance casted to the other interface.

                                   

                                  Again, I didn't check everything. It is very likely that there is huge bug in this concept.

                                   

                                  S,

                                  Ralf

                                  1 2 Previous Next