View Poll Results: If you read it, did you find DirectJNgine User's Guide adequate?

Voters
54. You may not vote on this poll
  • Yes

    40 74.07%
  • No

    14 25.93%
  1. #441
    Sencha User
    Join Date
    Nov 2011
    Posts
    77
    Vote Rating
    2
    yAdEs is on a distinguished road

      0  

    Default Extend with Jackson?

    Extend with Jackson?


    Thanks pagullo,great work!


    Your djn is awesome!
    I have made a directly ORM framework with Ext by djn, and It works well.

    The only suggestion is, do you consider to change gson with Jackson?
    It's much more efficiency and can easily extend to google app format.

    I changed it by myself, but I strongly recommand u change it,too.

  2. #442
    Ext JS Premium Member
    Join Date
    Jul 2008
    Location
    Miami, FL
    Posts
    56
    Vote Rating
    1
    omarc is on a distinguished road

      0  

    Default


    You modified the library to use Jackson instead?

    Is your version available anywhere?

    I'm very interested in taking a look at how it works.

    Cheers,

    Omar

  3. #443
    Sencha User
    Join Date
    Mar 2010
    Posts
    2
    Vote Rating
    0
    jpr is on a distinguished road

      0  

    Default Switch to slf4j for logging

    Switch to slf4j for logging


    What do you think about using SLF4J as a logging facade instead of hardcoded LOG4J for logging. This gives us the possibility to change/adapt &nbsp;to a logging framework used by the application which embeds DirectJNgine.<br><br>Steps are quite easy:<ol><li>Instead of log4j-1.2.15.jar use slf4j-api.jar and the binding slf4j-*.jar depending on the logging framework, you would like to use, e.g. slf4j-log4j12.jar</li><li>Import org.slf4j.Logger and org.slf4j.LoggerFactory, instead of org.apache.log4j.Logger</li><li>Change all Logger.getLogger( xxx.class) to LoggerFactory.getLogger( xxx.class)</li><li>Fix some errors, e.g. logger.fatal is not supported by slf4j, use logger.error instead</li><li>In DirectJNgineServlet.java change org.apache.log4j.NDC to org.slf4j.MDC</li><li>Instead of NDC.push/pull use the MDC map of slf4j (put/remove)</li><li>Adapt the logging statements to use placeholders instead of concatenated string (Performance)</li><li>On most occurences "if(logger.isDebugEnabled())" can be removed, as calling logger.debug() is not a performance issue anymore.</li></ol>Advantages: We use logback as our logging framework. This gives us the possiblity to set different log level at runtime. No need to restart the application. Depending of the application even a per session / per user logging in separate files is possible.<br><br>Any comments?!?<br><br>Jan<br><br>

  4. #444
    Sencha User
    Join Date
    Mar 2010
    Posts
    2
    Vote Rating
    0
    jpr is on a distinguished road

      0  

    Default Switch to slf4j for logging

    Switch to slf4j for logging


    What do you think about using SLF4J as a logging facade instead of hardcoded LOG4J for logging.

    This gives us the possibility to change/adapt to a logging framework used by the application which embeds DirectJNgine.

    Steps are quite easy:
    1. Instead of log4j-1.2.15.jar use slf4j-api.jar and the binding slf4j-*.jar depending on the logging framework, you would like to use, e.g. slf4j-log4j12.jar
    2. Import org.slf4j.Logger and org.slf4j.LoggerFactory, instead of org.apache.log4j.Logger
    3. Change all Logger.getLogger( xxx.class) to LoggerFactory.getLogger( xxx.class)
    4. Fix some errors, e.g. logger.fatal is not supported by slf4j, use logger.error instead
    5. In DirectJNgineServlet.java change org.apache.log4j.NDC to org.slf4j.MDC
    6. Instead of NDC.push/pull use the MDC map of slf4j (put/remove)
    7. Adapt the logging statements to use placeholders instead of concatenated string (Performance)
    8. On most occurences "if(logger.isDebugEnabled())" can be removed, as calling logger.debug() is not a performance issue anymore.
    Advantages: We use logback as our logging framework. This gives us the possiblity to set different log level at runtime. No need to restart the application. Depending of the application even a per session / per user logging in separate files is possible.

    Any comments?!?

    Jan

  5. #445
    Ext JS Premium Member
    Join Date
    May 2009
    Location
    Barcelona (Spain)
    Posts
    218
    Vote Rating
    19
    pagullo will become famous soon enough pagullo will become famous soon enough

      0  

    Default


    Quote Originally Posted by jpr View Post
    What do you think about using SLF4J as a logging facade instead of hardcoded LOG4J for logging.

    This gives us the possibility to change/adapt to a logging framework used by the application which embeds DirectJNgine.

    Steps are quite easy:
    1. Instead of log4j-1.2.15.jar use slf4j-api.jar and the binding slf4j-*.jar depending on the logging framework, you would like to use, e.g. slf4j-log4j12.jar
    2. Import org.slf4j.Logger and org.slf4j.LoggerFactory, instead of org.apache.log4j.Logger
    3. Change all Logger.getLogger( xxx.class) to LoggerFactory.getLogger( xxx.class)
    4. Fix some errors, e.g. logger.fatal is not supported by slf4j, use logger.error instead
    5. In DirectJNgineServlet.java change org.apache.log4j.NDC to org.slf4j.MDC
    6. Instead of NDC.push/pull use the MDC map of slf4j (put/remove)
    7. Adapt the logging statements to use placeholders instead of concatenated string (Performance)
    8. On most occurences "if(logger.isDebugEnabled())" can be removed, as calling logger.debug() is not a performance issue anymore.
    Advantages: We use logback as our logging framework. This gives us the possiblity to set different log level at runtime. No need to restart the application. Depending of the application even a per session / per user logging in separate files is possible.

    Any comments?!?

    Jan

    I like slf4j and the way it isolates you from the underlying logging system, and I thought about this some time ago, but decided against it.

    Why? The built-in log4j viewer (Chainsaw) + slf4j MDC + log4j adapter stack is less functional for "just-in-time" log analysis than the log4j NDC + built in viewer stack: NDCs are shown and can be filtered dynamically with the built-in viewer, MDCs are lost.

    Sometimes, that functionality is *very* useful for me, when debugging server side code. While writing DJN itself, it proved invaluable. Therefore, I could not justify back then spending extra effort to get less functionality in my own usage scenarios in order to get slf4j support.

    So, unless I get into a project that devotes some development time for me to do this, I do not plan to support slf4j in the near future. And, believe me, I would love to do it, as I know it would be useful in some scenarios
    Pedro Agulló, Barcelona (Spain)
    Agile team building, consulting, training & development
    DirectJNgine: http://code.google.com/p/directjngine - Log4js-ext: http://www.softwarementors.com/projects/p/log4js-ext/

  6. #446
    Sencha User
    Join Date
    Sep 2012
    Posts
    16
    Vote Rating
    1
    adavis2 is on a distinguished road

      0  

    Default


    Like n0n3 (who posted on 14-Jul-2012) I am also trying to implement a paged grid panel using a directjngine back-end. Actually, what I'd like to do is create a buffered (infinite) grid, where paging is handled when you scroll through the grid. Is it possible to do either of these things? If so, could you point me toward an example?

    Currently I'm able to display a grid panel with a paging toolbar and load the first page by subsetting the data to be returned. Unfortunately, I'm not sure how to pass back the total number of records (so the paging toolbar will show "Displaying 1 - X of Y" and enable the next button). How can I pass back the total number of records in the dataset?

    I feel like there will be more challenges to overcome before I can get a buffered grid working, but getting it working with paging is the first step.

  7. #447
    Touch Premium Member
    Join Date
    Jan 2011
    Posts
    55
    Vote Rating
    1
    maddhippy is on a distinguished road

      0  

    Default Sencha and forms

    Sencha and forms


    Hi, I'm using DJN with Sencha; It's been working perfectly until forms.

    When I create a form like is said in the docs as so:

    Code:
    Ext.define('mdms.mynote.view.components.MyNoteForm',{    extend: 'Ext.form.Panel',
        config:{
            hidden:true
        },
        constructor:function(config){
            Ext.apply(config,{
               url: Ext.mdms.BASE_PROVIDER_URL,
               api: {
                   submit:InsertNote.perform
               },
               items:[{
                   xtype: 'textfield',
                   name: 'descContact',
                   value: 'hello world'
               }]
            });
            this.callParent([config]);
        }
    });
    it throws this on my server:
    Code:
    SEVERE: Servlet.service() for servlet DjnServlet threw exception
    com.softwarementors.extjs.djn.router.processor.RequestException: Form post request is missing the following parameters: extAction, extMethod, extType, extTID, extUpload
    	at com.softwarementors.extjs.djn.router.processor.RequestException.forFormPostMissingParameters(RequestException.java:117)
    	at com.softwarementors.extjs.djn.router.processor.standard.form.FormPostRequestProcessorBase.checkNoMissingParameters(FormPostRequestProcessorBase.java:103)
    	at com.softwarementors.extjs.djn.router.processor.standard.form.FormPostRequestProcessorBase.process(FormPostRequestProcessorBase.java:61)
    	at com.softwarementors.extjs.djn.router.processor.standard.form.simple.SimpleFormPostRequestProcessor.process(SimpleFormPostRequestProcessor.java:62)
    	at com.softwarementors.extjs.djn.router.RequestRouter.processSimpleFormPostRequest(RequestRouter.java:69)
    	at com.softwarementors.extjs.djn.servlet.DirectJNgineServlet.processRequest(DirectJNgineServlet.java:609)
    	at com.softwarementors.extjs.djn.servlet.DirectJNgineServlet.doPost(DirectJNgineServlet.java:580)
    	at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
    	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
    	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
    	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
    	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
    	at java.lang.Thread.run(Thread.java:680)
    I am trying to submit like so:
    Code:
    form.submit({
                params:{
                    test:'test'
                },
                success:function(form, action){
                    console.log('success')
                },
                failure:function(form,action){
                    console.log(form);
                }
            });
    It seems from those errors that the form submit does not go through the Ext.direct router and the Ext.direct metadata properties are not being added. Is there something additional I need to be doing here?

    Thanks

  8. #448
    Ext JS Premium Member
    Join Date
    May 2009
    Location
    Barcelona (Spain)
    Posts
    218
    Vote Rating
    19
    pagullo will become famous soon enough pagullo will become famous soon enough

      0  

    Default


    DJN works with forms from the very first version. I suspect there is some configuration error or some missing step in the javascript side -I think you are using the right annotation in the Java side, but just check it.

    The DirectJNgine code includes some tests that exercise this feature, you might want to take a look at the javascript/java code.
    Pedro Agulló, Barcelona (Spain)
    Agile team building, consulting, training & development
    DirectJNgine: http://code.google.com/p/directjngine - Log4js-ext: http://www.softwarementors.com/projects/p/log4js-ext/

  9. #449
    Sencha User
    Join Date
    Dec 2012
    Posts
    2
    Vote Rating
    0
    mark.peters is on a distinguished road

      0  

    Default DJN 2.2 does not support form submit for ExtJS 4.1

    DJN 2.2 does not support form submit for ExtJS 4.1


    Quote Originally Posted by pagullo View Post
    DJN works with forms from the very first version.
    Hi Pedro. I'd like to detail some issues I had when using DirectSubmit (ExtJS 4.1) with DJN 2.2. My experience would lead me to say that DJN has not yet been updated to support form submit for the latest version of ExtJS.

    The issues all revolve around the fact that DJN's responses to form submits do not at all conform to the specified responses here: http://docs.sencha.com/ext-js/4-1/#!...n.DirectSubmit (see "sample success packet" and "sample failure packet"). This bug manifests itself in different ways:

    1) No support for void @DirectFormPostMethod methods.

    A void method that completes normally (without exception) will have the "failure" callback called in ExtJS because DJN's response has the "result" property set to null.

    My current workaround for this bug has been to always return an object from form post methods, which has a success field hardcoded to true. Another workaround is to return a boolean and return true if the method completes successfully.

    2) No support for exceptions thrown from @DirectFormPostMethod methods.

    When a form post method throws an exception, DJN will send the serialized StandardErrorResponseData class. This does not have a "result" field as required, with a "success" value set to false. As a result, ExtJS will call the failure callback, but will do so for the wrong reason. ExtJS treats it (and other malformed responses) as a connection error, rather than a server error. The error metadata (message, serverException, etc) are not available to the callback.

    I've looked at the DJN test for this case, and it is wrong. The test verifies that the callback is called, but was changed for ExtJS 4.1 to expect a "connect" failure instead of a "server" failure. This is not correct.

    My current workaround to this issue is to add custom GSON serialization when serializing StandardErrorResponseData, to rewrite the response into what ExtJS expects. This involves adding an object property named "result" with a "success" property set to false, and then moving the "message", "serverException" and "where" objects into that result object (otherwise they will not be available in the callback).

    So as I said, I think there's a little ways to go before it could be said that DJN 2.2 supports form submit for ExtJS 4.1. But this has been the first major defect we've found in DJN; our experience with it in general has been positive. Thanks for your work on it.

  10. #450
    Sencha User
    Join Date
    Dec 2012
    Posts
    22
    Vote Rating
    0
    lee el is on a distinguished road

      0  

    Default Provider is not defined

    Provider is not defined


    Hi,

    I started to use DirectJNgine and I was able to configure it and use it within extjs app.
    I regiester it in my main script file app.js as follows:

    Code:
    Ext.application({
        
        name: 'App',
        appFolder: 'app',
        launch: function() {
            Ext.Direct.addProvider(MyProvider.direct.REMOTING_API);
    and then I am able to call the java classes and methods.
    the problem is when I change some file my server redeploys the APP and then I get an error about the provider:
    Uncaught ReferenceError: MyProvider is not defined

    only when I restart my server the problem is solved, I would like to have suggestions why this is happening
    is there some king of log?
    thanks,
    Lee

Thread Participants: 86

  1. Animal (5 Posts)
  2. barton (4 Posts)
  3. Condor (1 Post)
  4. mauro_monti (6 Posts)
  5. mbarto (1 Post)
  6. aconran (1 Post)
  7. MoShAn480 (1 Post)
  8. asgillett (2 Posts)
  9. seade (4 Posts)
  10. zaqwsxqwer (3 Posts)
  11. Sesshomurai (16 Posts)
  12. ThierryC (3 Posts)
  13. maxm165 (3 Posts)
  14. techstudios (2 Posts)
  15. sayonara (2 Posts)
  16. kschlaudt (1 Post)
  17. hschaefer123 (2 Posts)
  18. omarc (2 Posts)
  19. lxbzmy (4 Posts)
  20. mct (6 Posts)
  21. mediacept (2 Posts)
  22. dionisexorcius (1 Post)
  23. alper (1 Post)
  24. steverc (2 Posts)
  25. chrizmaster (18 Posts)
  26. J@y (21 Posts)
  27. Georgioa (6 Posts)
  28. wguan (1 Post)
  29. minneyar (16 Posts)
  30. jhoweaa (1 Post)
  31. Ramez (2 Posts)
  32. malus (1 Post)
  33. dweller (8 Posts)
  34. stdunbar (1 Post)
  35. vlagorce (20 Posts)
  36. cwilliso (1 Post)
  37. Whatty (13 Posts)
  38. Ice (1 Post)
  39. clynnh (1 Post)
  40. SreevaniN (1 Post)
  41. Stsalomon90 (1 Post)
  42. GregT (9 Posts)
  43. jcalfee (6 Posts)
  44. set_ti (1 Post)
  45. maho2nd (3 Posts)
  46. dreamtaotao (3 Posts)
  47. Toxa (4 Posts)
  48. tungchau (3 Posts)
  49. wlan0 (2 Posts)
  50. jpr (2 Posts)
  51. gianmarco (5 Posts)
  52. extjslikeit (2 Posts)
  53. harmen_wessels (1 Post)
  54. Olivercomputing2 (4 Posts)
  55. vanessa_ng (2 Posts)
  56. alois.cochard (5 Posts)
  57. kyrillos52 (2 Posts)
  58. Tod (1 Post)
  59. Alinanila (1 Post)
  60. tfannon (2 Posts)
  61. Kynao (1 Post)
  62. feiq (4 Posts)
  63. dalt (1 Post)
  64. xfolch (1 Post)
  65. avijit (1 Post)
  66. marcelsnews (2 Posts)
  67. maddhippy (1 Post)
  68. sritter (1 Post)
  69. july (2 Posts)
  70. jtkeller7983 (1 Post)
  71. lfranchini (2 Posts)
  72. 7/11 (2 Posts)
  73. yAdEs (1 Post)
  74. zazz (1 Post)
  75. waqar (5 Posts)
  76. pjain11 (1 Post)
  77. alexMobimesh (2 Posts)
  78. zachHurt (4 Posts)
  79. n0n3 (5 Posts)
  80. adavis2 (1 Post)
  81. mark.peters (1 Post)
  82. lee el (4 Posts)
  83. frengo19 (3 Posts)
  84. prakashwagle (1 Post)
  85. extejnar (2 Posts)
  86. alin@sonatype.com (1 Post)
Turkiyenin en sevilen filmlerinin yer aldigi xnxx internet sitemiz olan ve porn sex tarzi bir site olan mobil porno izle sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli porno izle siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir. Mesela diğer sitelerimizden bahsedecek olursak, en iyi hd porno video arşivine sahip bir siteyiz. "The Best anal porn videos and slut anus, big asses movies set..."