Ok, I am uisng GWTP, it got Client, Server & Shared package.
I have a Util class in client.
my.client.Util.java{
public static String method1();
//more methods here
}
In server i have
my.server.GetDataActionHandler{
///Should I do like this
String s=my.client.Util.method1();
}
Is it safe to do that or I should put Util into shared package, like this
my.shared.Util.java{
public static String method1();
//more methods here
}
What is the different if we put a Util in shared package? is it safer or any other good reasons?
client is as safe as shared, these are just names and conventions.
By placing your class in client though, you lose the indication that you're using it also on the server side, where client-specific code won't run.
By placing it in shared, you're signaling to yourself that you should make sure the code your put in the class can effectively be used in both the client and the server.
Read here about GWT MVP atchitecture
Read more here about GWT Architectural Perspectives
Accessing client side code from server side will become your code tightly coupled. Shared package is used for this purpose but still its not for any UI specific code. Shared packages is used to define some DTO (Data Transfer Object) and Utility classes.
There is no meaning of accessing any GWT UI specific utility classes at server side.
Try to decouple your code in such way if in future you want to use your server side classes for Swing application or any other web application other than GWT then you can easily incorporate it. Think about it.
Related
I want to share an interface between two applets as client and server with different package AID. I saw the link: [0x6f00 error casting Javacard Shareable Interface
In the above link is said: both client and server have to be in same package.
I have a question now. is it possible client uses server functions if they have different package AID?
Thank you very much.
Client and server don't have to be in the same package! They just both need to depend on the same package, which contains the shared interface.
In the linked question, there was a problem with interfaces: OP declared two interfaces with the same name in two separate packages. That is why casting failed and 6F00 status was thrown.
How to use Shareable interface:
1.Declare your shared interface public in your server-side package:
package com.test.mypackage.a;
public interface SharedObject extends Shareable {
public void foo();
}
2.Use the interface in your client code:
package com.test.mypackage.b;
import com.test.mypackage.a.SharedObject;
...
SharedObject obj = (SharedObject) JCSystem.getAppletShareableInterfaceObject(svrAid, (byte)0);
Use your server applet as a library when building your client applet.
Load your server applet cap file first.
Then load your client applet cap file.
Shareable interface cannot be used for applets in same package.Since it works for applets with different contexts.
Shareable interface is used when one applet(Client Applet) need to access methods from another applet(Server applet) provided both the applets are located in different packages.Applets in different packages are separated by a firewall to prevent access to applet data across package.
Please check this simple implementation for shareable interface it will clear your doubts about its use case.
https://stackoverflow.com/a/57200926/4752262
I share a Data Transfer Object between an C# Azure Mobile Services server and client. I use the same class in both applications.
The TableController class used by Azure mobile services requires the DTO to inherit from 'EntityData', which in turn implements interface 'ITableData'.
ITable Data lives is part of reference:
Microsoft.WindowsAzure.Mobile.Service.Tables
I have not figured out how to include that reference without installing the entire server-side mobile services package in nuget:
WindowsAzureMobileServices.Backend
That includes OWIN, and many other references the client does not need. This is what I am doing currently. This works for a desktop application I am currently working on, but I think it will not work for universal apps and windows phone apps.
I also looked at microsoft's samples for mobile services, and there they use separate classes as DTOS for server and client.
Is it really the case that we have to write the same code twice?
No, but you could better make use of Shared Projects, and partial classes.
Your Shared Project will have common properties for the entities.
Other projects will reference this Shared one, and can add some other properties to shared entities, still using partial classes.
I have precise experience with AMS, so I know what you are meaning.
In my experience, is anyway not realistic to think to have exactly the same entity classes for client and server.
For instance, in so called Portable Class Libraries you can have a very small subset of framework, and references available.
Other than properties, you normally put attributes on POCO class files. On the client you may have some attributes that aren't available/meaningful for the server (e.g. SQLite attributes), or viceversa. You may can get stuck in this situation also with the shared projects approach I suggest, but it could be managed there with what so called preprocessor directives.
I've searched as much as I could but did not find any answers/examples for my question.
I'm completely new to Web UI development but have a decade and a half of experience in Java and other languages. I seem to be completely lost in the sea of available options for the client side, but for the server side I have a Rest server (Play) running already. I can't and don't want to use a complete package for both client and server b/c I want to pass JSON back and forth between the server and the client. This way I can use multiple different clients: web, Excel, Swing, etc. I want to keep it flexible like this.
So far I pretty much decided to use GXT for the client side, and found RestyGWT to be sitting in the middle. This is what causes my problems. So far, I have not been able to find a single example of a GXT + RestyGWT combination. Just a single example (a Grid for example) would be extremely helpful, since I have no experience with J2EE, beans, or any of that.
Any help or examples with GXT + RestyGWT would be greatly appreciated!
What have you tried? RestyGWT is serialization and transport, so ideally you set up a loader that describes what you need based on your widgets (grid? paging toolbar? filters?), and then pass it a DataProxy implementation that knows how to take config objects, and asynchronously send back loaded data objects. Each grid example that loads from the server uses a loader, but a different proxy (and optionally reader) based on whether it us using RPC, RequestFactory or XML/JSON over HTTP. There is also a JSONP example, and while it isn't using the Grid, it is still loading items to a ListStore, so could easily be attached to a grid.
DataProxy is a simple interface - it is given a config object and a callback to invoke when the load is finished or to notify if an error occurred. In your implementation of this interface, call your service with the necessary details of the config, and then invoke the callback when results are ready.
If you want an example of how RestyGWT works you can have a look to
one of my blog article. It is a pure GWT example but should work with GXT as well. GXT is mostly about graphical components for GWT.
In 2 words you need to
1) Define your restServices interfaces
public interface HelloClient extends RestService {
#GET
public void getHellos( MethodCallback<List<Hello>> callback);
}
2) Create your client
HelloClient client = GWT.create(HelloClient.class);
3) Use it
client.getHellos(new MethodCallback<List<Hello>>() {
public void onSuccess(Method method, List<Hello> response) {
//...
}
public void onFailure(Method method, Throwable exception) {
//...
}
});
On a project I'm working on I'm trying to develop a generic mechanism for sending back messages from anywhere in the code base to the front end for possible logging, displaying to the user etc.
Messages could be sent because of an error/exception, to report progress etc. Initially I thought of using something like log4net to report the message data and have a custom appender at the application level to consume these messages and then display them/log them as appropriate. However I'm not sure that this is the best approach because of a couple of issues
1) The project is split across a number of separate assemblies and I've seen that there are issues with configuration of log4net across multiple dlls.
2) This messaging scheme is more than just logging, so using a logging framework may be too restrictive.
At the moment I'm using C# custom message events to send data from assemblies and registering a handler at the application level to capture them.
However I've realized that the the Messenger class in MVVMLight is exactly what I'm looking for, a way to send a generic data packet (class) across assemblies. But because I could be sending messages from model code I'm wondering if this is adding unnecessarily dependencies to MVVMLight in to the model code.
My impression is that the Model code should be as dependency free as possible so that it could be dropped into any application framework without modifications.
What do you guys think?
If that's what you're trying to do then you should use the Messenger class.
How likely is it (really) that the model code is going to be used by another application? If it's something generic (user preferences, security, etc) then you might want to use it elsewhere but if you're providing bespoke business data then YAGNI.
From a good practices perspective I'd suggest doing something like this:
public interface IMessenger<T>
{
public void Send(T message);
}
public class MessengerProxy:IMessenger<ErrorDto>
{
public void Send(ErrorDto error)
{
Messenger.Default.Send(error);
}
}
public class AnotherModel
{
public AnotherModel(IMessenger<ErrorDto> errorRegister)
{
_errorRegister=errorRegister;
}
private RegisterError(Exception ex)
{
var dto=new ErrorDto(ex,"My Title");
_errorRegister.Send(dto);
}
}
Register the MessengerProxy in MVVM Light and have it injected into the constructor of your Model classes. In my model class, above, I inject the interface into the constructor. This gives me access to the Messenger but allows me to change the underlying implementation if I need to later on.
I am trying to develop a Spring Roo/GWT app with the newest integration of GWT in Roo.
Getting the scaffolding to work is very straightforward, but I don't really understand how the RPC works there.
Can someone of you provide a simple example how to do a simple service to connect client/server within Spring Roo and GWT.
Would be very helpful for a start, as I couldn't find any resource on that.
thx & regards,
Flo
Flo,
Not sure if you are up on google wave at all, but that does seem to be one place to keep apace of the current effort. Specifically this wave is available to the public:
RequestFactory Wave
It covers the details (well emerging details) about the RequestFactory API.
The basic idea is that your domain model objects are needed on the server side and the client side. Using hibernate can cause issues with the class files and people have wound up having two sets of model objects, and using custom GWT-RPC to make server requests and marshall/un-marshall between the client- and server-side model objects. Not an ideal solution. Even if you can use the same model objects, the overhead of the RPC is a drag.
Enter RequestFactory and we see that google engineers are probably getting paid what they are worth. Take a look at the sample code generated from the .roo - specifically ApplicationRequestFactory.java.
package com.springsource.extrack.gwt.request;
import com.google.gwt.requestfactory.shared.RequestFactory;
public interface ApplicationRequestFactory extends RequestFactory {
ReportRequest reportRequest();
ExpenseRequest expenseRequest();
EmployeeRequest employeeRequest();
}
This is an interface that provides request methods for each of the domain objects. There is no implementation of this class defined in the project. It is instantiated in the EntryPoint with a call to GWT.create(...):
final ApplicationRequestFactory requestFactory =
GWT.create(ApplicationRequestFactory.class);
requestFactory.init(eventBus);
Within the com.springsource.extrack.gwt.request package you will see an ApplicationEntityTypesProcessor.java which is cleverly using generics to package the references to the domain classes for use later in the presentation. The rest of that package though are events and handlers for each model object.
Specifically there are four auto-generated classes for each object:
EmployeeRecord.java - This is a DTO for the domain object.
EmployeeRecordChanged.java - This is a RecordChanged event to provide a hook method onEmployeeChanged.
EmployeeChangedHandler.java - This is an interface that will be implemented when specific behaviour for the onEmployeeChanged is needed.
EmployeeRequest.java - This is an interface used by the ApplicationRequestFactory to package up the various access methods for a given object.
Keep in mind there is a lot of code generated behind the scenes to support all this. And from M1 to M2 a lot has been cleaned out of what is visible in a GWT project. I'd expect there to be more changes, but not as drastic as M1 to M2 was.
So finally these events can be used as in the UI package to tie together the domain and the UI. ReportListActivity.java:
public void start(Display display) {
this.registration = eventBus.addHandler(ReportRecordChanged.TYPE, new ReportChangedHandler() {
public void onReportChanged(ReportRecordChanged event) {
update(event.getWriteOperation(), event.getRecord());
}
});
super.start(display);
}
Again I refer you to the wave for more info. Plus the expenses.roo demonstrates how to use Places and has a rather slick Activity framework as well. Happy GWTing.
Regards.
The functionality you are referring to is currently under heavy development (or so the guys at Google want us to believe ;)) so the API and internal workings are not final and will most likely still change before the final release of GWT 2.1 (this was stated a few times during the GWT sessions during Google IO 2010). However, you can browse the Bikeshed sample in the trunk to see a working (hopefully ;)) example. There's also the 2.1 branch that appears to contain the up-to-date (?) sample (and the cookbook that was promised on Google IO).
Personally, I'd wait with switching your code to the new RPC model till the guys working on GWT say it's safe to do so ;) (but it's definitely a good idea to get accustomed with the general idea now - it's not like they will change everything :D).