Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • Isomorphic
    replied
    Ah, so you are calling a REST service from the server, and the POJOs were generated from the REST interface.

    Yes, this is an example of a Custom DataSource and it does make sense to use the server framework. You will probably want the DataSources you expose to the browser to be simpler that the POJOs generated from the XML REST service (since you mentioned 32 POJOs, which seems like a lot for one logical business object).

    A key server-side API you can use to populate these POJOs in DataSource.setProperties() / getProperties() as well as dataSourceField.valueXPath.

    Leave a comment:


  • p27939
    replied
    Let's just say that the custom REST interface that I'm connecting to is in the cloud and I can't modify it. It'll produce some XML, defined by XSD, which I'll have the generated beans for so that I can easily marshall and unmarshall the XML.

    I was thinking that we'd like to take advantage of the SmartGWT Java Server framework. It sounds like I would just treat this interface as just a custom persistence framework and implement a custom data source within the Java Server Framework. That way I can take advantage of many of the benefits that a Smart client has by relying on the Smart server.

    Leave a comment:


  • Isomorphic
    replied
    Ah, it would have been great to know that REST was the situation, which changes a lot. But now we're not sure of the architecture at all here.. are these REST APIs between the browser and the server? If so, then why are you looking at the JPA entities at all? You're binding to the REST services, so the JPA information would seem to be rather different. Presumably the REST services do not, for example, involve any information about inheritance.

    Also, carefully consider this FAQ which talks about why pre-existing REST interfaces are usually inadequate for the needs of a UI, and consider whether you're really really locked into these interfaces.

    Leave a comment:


  • p27939
    replied
    Let me try to be a little more specific to make sure that I get it or not. (probably not).

    The entire back-end system that I'm connecting to has a custom REST interface that I'm not able to change. Therefore I don't believe that I can use any of the stock connectors. Which would leave me to implement a custom DataSource class for the server, right? (to marshall/unmarshall etc...)

    I would then write 1 (or more) DataSource descriptors (on the client side) that would define the data that I want to expose to the end user and bind to components.

    Now does that sound right?

    Thanks.

    Leave a comment:


  • Isomorphic
    replied
    No, that's not correct - you could, for example, have a leaf POJO that is mapped to JPA with various superclasses that exist only for server-side housekeeping purposes. In that case you might use a stock JPADataSource for this leaf POJO and never create DataSources for it's superclasses.

    Likewise, we don't have examples of inheritance because "inheritance" is very rarely a word in an end user's vocabulary, so it's not typically part of the model as projected into the browser.

    For "composition" substitute "relation" - the EE Showcase has examples of the core types of relation with JPA (1-many, many-many).

    Leave a comment:


  • p27939
    replied
    So just to be clear then, it sounds like I need to implement a custom DataSource class, to be run on the server-side, that understands my application's data model and have multiple DataSource descriptors (ds.xml) that only expose the part of the data model that is necessary to populate data-bound components.

    Does that sounds right?

    Also, can you point me to an example for a complex DataSource descriptor that does some composition and inheritance?
    Last edited by p27939; 1 Jun 2012, 12:04.

    Leave a comment:


  • Isomorphic
    replied
    What you need to consider is how much of that complexity you want to project into the browser and the UI. Most likely you have things factored into a bunch of separate beans for reuse and housekeeping purposes but there are only a few different entities in the UI and/or the end user's cognitive model of the data. Those are the ones where you want DataSources, the rest are details which need only exist server-side.

    Leave a comment:


  • p27939
    replied
    Maybe you can help inform me of my situation. Technically, I have one business object, however, itís pretty complex. Itís comprised of 32 bean classes with varying levels of composition and inheritance. The examples Iíve seen are pretty flat and simple (i.e. primitive types with no composition). So does that mean that I have one DataSource or do I have 32? If I have 32, then that is why Iím looking at the batch data source generator.

    Leave a comment:


  • Isomorphic
    replied
    The comment you found in the source is a little misleading in that it means JPA POJOs. Again, in the QuickStart Guide we explain how to derive DataSources on the fly from true POJOs (no Hibernate/JPA) by setting just one property. If your use case doesn't call for Batch DataSource Generator, there's no point troubleshooting further.

    Leave a comment:


  • p27939
    replied
    I think we're finally at the crux of the issue. I'm not using hibernate and I don't plan on using hibernate. So this sample project is appropriate from that perspective. This sample project error-ed out with a 404 even when I had a real bean class in there. So the problem is that it's looking for the hibernate configuration and one is not there.

    The documentation says that I can generate a ds.xml from Java Beans, which is what I'm trying to do. The visual builder can successfully generate a ds.xml from a Java Bean from this project without any hibernate configuration.

    I must be missing something conceptually, why does a project have to have hibernate configured to use the Batch DataSource Generator?

    Thanks.

    Leave a comment:


  • Isomorphic
    replied
    That sample project doesn't have Hibernate configured or a foo.Bar bean, so this would be expected to error out even though that might not be the clearest error message. Try it in the hibernate sample project to see it working.

    Leave a comment:


  • p27939
    replied
    Actually, itís pretty easy to reproduce.

    1. Download and unzip latest build (see version below)
    2. cd into the samples/builtinds directory
    3. ant
    4. ant hosted
    5. goto URL: http://127.0.0.1:8888//builtinds/tools/batchDSGenerator.jsp?className=foo.Bar

    and you should get the following error:

    HTTP ERROR: 404
    C:\smartgwtee-3.0p\samples\built-in-ds\war\WEB-INF\classes\hibernate.cfg.xml (The system cannot find the file specified)
    RequestURI=//builtinds/tools/batchDSGenerator.jsp

    SmartGWT version from Dev Console:
    SmartClient Version: v8.2p_2012-06-01/EVAL Deployment


    From the documentation, I should be able to do this, right? I don't want to use hibernate, I just want to generate a ds.xml for a given bean class.

    Leave a comment:


  • Isomorphic
    replied
    We're not sure yet how you're in this state (we don't see a 404 or similar problem in the SDK after following a normal install).

    However, one quick sanity check - do you have a need to generate dozens of DataSources at once, where you need to customize the generation process to take advantage of custom Java annotations or similar additional metadata?

    If this isn't your use case, don't use the Batch DataSource Generator, just use the approaches from the QuickStart to declare DataSources with autoDeriveSchema.

    Leave a comment:


  • p27939
    replied
    I dove into the JSP and called the batchDSGenerator.jsp with the URL parameter of my class and I get a little more expressive error:

    Code:
    HTTP ERROR: 404
    
    ...\extree\war\WEB-INF\classes\hibernate.cfg.xml (The system cannot find the file specified)
    
    RequestURI=/extree/tools/batchDSGenerator.jsp
    From the following comment in the JSP, it looks like it's actually failing to fallback to the Java Bean because it can't find the hibernate config file.

    Code:
    It can also generate DataSource definitions directly from Hibernate mapped entities or POJOs
    that follow Javabean naming semantics (ie, property foo is accessed with getFoo() and setFoo()).
    In this case, provide any number of "className" parameters - these will be interpreted as 
    Hibernate entity names first, then as fully-qualified Java class names if they are not found
    as Hibernate mapped entities.  Example usage:
    
    http://localhost:8080/tools/batchDSGenerator.jsp?className=OrderItem&className=org.bar.foo.MyClass
    I'm not trying to use hibernate, I'm just trying to do a POJO bean.

    Thanks.

    Leave a comment:


  • p27939
    replied
    After taking a closer look, there are actually two JSPs for the Batch DataSource Generator.

    dsGenerator.jsp
    batchDSGenerator.jsp

    The first one is the one that brings up the dialog shown in the attachment called dsGenerator.gif.

    The 404 occurs after I populate the class name and hit the "ok" button. The 404 is on the "batchDSGenerator.jsp".

    After noticing this, I just to open just the batchDSGenerator.jsp and I get the screen that is attached and called batchDSGenerator.jsp.

    I also attached the output from the results tab.
    Attached Files

    Leave a comment:

Working...
X