• Organization of the Tools/Code

    By Jack Ratcliff 2 decades ago

    Hi Everyone,



    The scope of this project is to provide Domino Web Developers with code that can be plugged into web applications. With that thought in mind, should we store all of this common, reusable code into one database or should there be multiple databases?



    For instance, I have code to take any view and convert it to html. I also have a really super cool date picker and rich text editor. Since these tools do accomplish different tasks, should we keep them in their own separate dbs or combine them and other code we gather into one db???

    • Multidb versus one db

      By Werther D. Vervloet 2 decades ago

      Hi Jack,



      finally we have a workspace to work! About the question above, I think we can organize all codes in one single database in the end. But I think when we are actually working in the project, it's easier to mantain multiple databases, so we can work at same time in more than one feature. What everyone think?



      Another question. What do you think in describe every feature that we want to develop in the project? With this, anyone can post a message to tell us if they already has some working code.



      Regards,



      Werther

      • Agreed

        By Jack Ratcliff 2 decades ago

        Hi Werther,



        I agree. Let's keep each feature in a separate db during development and we'll roll all dbs into one db for each release.



        Jack

      • webView info

        By Jerry Malsam 2 decades ago

        We're using the older client-side XML views (with a lot of customizations), which look great, but they have some issues that I'd like to solve in a generic way (for future projects as well). Namely, we're having some bizarre problems loading and transforming the XML over our WAN, but more fundamentally, the client-side XML puts a significant burden on the user's platform setup and configuration.



        For now, I'm mostly interested in the "webView" aspect of this project, so I'll throw out some suggestions/ feature requests:


        1. Minimize client platform requirements (i.e., require no client-side XML transform, no JVM, no Flash, etc.).
        2. Work w/ both r5 and r6 servers. This may rule out some of the DXL stuff and/or limit server-side XML transformation.

          3. Take view design structure (column values, order, initial sort, categorization) from Notes design – for a counter-example, see http://www-10.lotus.com/ldd/sandbox.nsf/ByDateNJ/b611faeb15138c0a85256dbf0052b24c?OpenDocument (I don't like how this app uses documents to specify the view design, but it's a must-check-out for some inpiration on the interface!)
        3. Use CSS for specifying/customizing layout style – this implies that the generated HTML will need columns, rows, column titles, etc. tagged with class names
        4. Retain (at least) Notes style robust document selection, e.g., select one, many, all shown, or all total documents, either using checkboxes or row highlighting.
        5. Retain Action Button functionality that works with the document selection, i.e. don't require custom javascript functions for document deletion (I may have a solution for this.)
        6. Preserve categorization.
        7. Enable column sorting (within the displayed documents is easy, but how to do this interface-wise for ALL documents?).

          8a. Enable starting view at a specified document – should be easy with "Start=xx" or "StartKey=XxXxX" URL parameters.

          8b. Provide facility for returning user back to their place in the view after editing/saving/closing a document. (I get asked for this ALL THE TIME!)



          Of course, with all these suggestions, I'm very willing to help. It'd be great to have a plug-in solution for this – something like a .js file and a few .css files to stick in the $$ViewTemplate header, no custom-scripting required…



          Is there a work-in-progress .NSF for the webViews around here somewhere?
        • Great Ideas

          By Jack Ratcliff 2 decades ago

          Hi Jerry,



          Great feedback. Some of the items you mention are already covered in the current xml-xslt.nsf sample db posted in the code bin



          http://www.openntf.org/Projects/codebin/codebin.nsf/0/3B006475E3B5BCDE88256C4800728BCA



          I'll take a look at the sample you have mention that is in the sandbox as well.



          Jack

          • What approach?

            By Jerry Malsam 2 decades ago

            Yes, it looks like we're all on the same page as far as desired functionality, although I'm not sure about the best way to get there. Past posts imply that you're looking to do the XML transforms server-side, possibly with a servlet. (?)



            Can the servlet be written and setup in a generic way? Something like: INPUT = user authentication + xml url + xsl url; OUTPUT = html. Or will it need to be customized for each application? It'd be nice to get it down to one generic server installation package, ideally including all the necessary components.



            It's great to off-load the XML/XSL processing from the client, but what advantages does server-side XML/XSL processing have over just parsing out the XML with javascript? Seems to me it requires a significant amount of additional developer expertise (java, XSL, server configuration) without much additional payoff, okay maybe off-loading a bit of javascript processing from the client. Can you confirm whether user authentication via servlet (to return only the data that user should see) is even possible?



            Weird idea: Would it make sense (or even be feasible) to offer 3 possible solutions for 3 different scenarios?

            1. Client-side XML/XSL processing using MSXML object – good choice for well-defined/controlled clients, no server configuration required.
            2. Server-side XML/XSL processing using java servlet – good for low-end, poorly controlled clients, requires some server config.
            3. Client-side javascript parsing (no XSL) – requires a little more client processing power than #2, good for poorly defined clients, no server config.



              Of course we'd want to develop generically, using common components between the 3 approaches, where possible.



              Is there a spec or even some dev dbs we can start building upon? I really want to help with this if you've got room for one more.