5 Replies Latest reply on Sep 14, 2004 11:30 AM by Dennis Przybyla

    Gallery module

    kenny1 Newbie

      A friend of mine was just looking at jboss-nukes, and thought it would be nice for jboss/nukes to have a gallery module. Yep, same here. If someone like him were to develop or port a well-established one(gallery, coppermine, etc) for jboss, what projects would you suggest to port from or to look at?

        • 1. Re: Gallery module
          Thomas Heute Master

          Yes ! I wanted to do one at first then i came up fixing what was already there. That would be great to have a gallery (and a Calendar if any picker hear that ? ).

          I liked Gallery 2, even though i didn't really look into all the features. I didn't even know coppermine... So i am not a good advisor for picking a project, any you can take the best of several projects, to make THE gallery :)

          If you decide to go ahead and code, let us know, we have some recommendation to keep Nukes tight together.

          • 2. Re: Gallery module
            kenny1 Newbie

            Thanks for reply Thomas. G2 is nice and better written than G1, but most of all, G2 is database driven.

            For the time being, I am reading the gallery doc and code, trying to get a grasp of it. I am not familiar with php but interestingly I find use of inheritance in php .class files, which would make porting easier than from G1. Anyhow there is a long way to go before actual coding. Would you mind throwing us some recommendations you have in mind for now? That way, in my opinion, would let us further understand how a module interacts with the core engine or other facilities. A Calendar module is a great idea too. But just wondering what features it would/should have becoz I haven't found any related on the web.

            • 3. Re: Gallery module
              Thomas Heute Master

              As we are getting more and more organized, it would be nice if contributors could respect some coding rules, so that it's easier to maintain. It is not a MUST-DO, rather a BETTER-IF-YOU-DO. Feel free to do your own way if you really want to. I don't want to stop you in your efforts.

              (I am detailing so this thread can be useful for anybody wanting to contribute)

              Now here are some stuffs we would like to see for modules:
              1) Respecting the JBoss code style. It's all explained here: http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/guides/codestyle
              It still gives lot of freedom. If you use Eclipse i could send you my settings (so that when you press tab, it creates 3 spaces as defined by the JBoss code style)

              2) Use an internationalization key for every sentence printed on screen (resource properties) and create the file for us_US

              3) For internationalization keys, use the following style:
              - Only 1 file per module.
              - Classify the keys into sections and precede the key by the name of the section then _ you can have subsections. It's not clear so here are some examples that could work for a gallery:

               // Administrate images
               ADMIN_IMAGE_DELETECONFIRM=Are you sure you want to delete this picture
               ADMIN_IMAGE_MODIFY=Modify this picture
               // Administrate albums
               ADMIN_ALBUM_DELETECONFIRM=Are you sure you want to delete this album
               // Images stuff
               IMAGE_NAME= Name of the image
               // Albums stuff
               ALBUM_NAME=Name of the album

              I guess you got the idea, of course a better division could be better, it's up to you

              4) We are making good use of the Command pattern, we could easily add a logging feature (we don't do yet). The best thing to do is to look at how it works in BB and News, but in few words: For every action of a module (Creating an image, Updating an image, Deleting an image, Creating an album, Updating an album...) we create a Command, that command usually has few public methods like execute that executes the command, we could add an "unexecute" method to easily rollback. Another interesting thing, we can combine actions (an update could be the combination of deleting and creating (it is a bad example as it doesn't work in most of the case, updating something keeps the id).

              5) it goes with 4), the use of interceptors. an easy way to add some behavior to a module, is to create interceptors. For example in the forum, when you post a message, it first goes through an interceptor to check if you didn't post in the last seconds (and not flooding the forum).
              In news module there is not interceptor but here how the code looks like
              public NewsModule()
               // Starts the chain of Interceptors
               chain = new CompositeInterceptor();
               executeInterceptor = new ExecuteInterceptor();

              To add an interceptor (let's say to check the spelling), we would just have to add a setNext(mySpellingInterceptor) to the chain.

              6) Use of EJBs and CMP like any other existing module.

              That's all about what i think about right now.
              To actually make a new module you can first take a look at RSSModule, it's about 100 lines, then look at BB, News or Downloads

              Again, that would be very nice to follow those recommendations, but it's only recommendation, i hope i didn't scare you away.

              Any question ? Feel free to ask in this thread. (Anybody)

              Julien (cooper) may have some other recommendations, or may correct me.

              (about the calendar, there are some in every groupware, the following look nice :

              • 4. Re: Gallery module
                Viet Master

                My 2 cents :

                Modelise first the database as CMP entity beans with fields and relationship.
                Once you have that (maybe not entirely at the beginning, a subset can be enough) you can start port the module.

                G2 seems big, so there is no particular advice I could give and according to how the code is done, the way to port can be different. There is no magic here.

                Usually I try to make the basic functionnalities work then I complexify the thing.

                • 5. Re: Gallery module
                  Dennis Przybyla Novice

                  Idid briefly look at the different gallery modules a while back because I was interested in porting one. What I found is that some of them use a library to do some of the graphic manipulation. I would suggest that you find a java lib that can do the same things as the ones that where used for the other projects. I started looking for a java graphic library to do this and was supprised that there where some out there but didn't get a chance to look any further.