We know that CGLIB provides several Callback implementations, with the most useful one of MethodInterceptor. However, how about other ones(FixedValue, Dispatcher, LazyLoader, NoOp, ProxyRefDispatcher) ? I browse the API document but can not get useful information. Can anyone show how and when to use these Callbacks in what scenarios ? I read the related code in Spring but I am still puzzled.
Thanks!
I wrote a summary of all callbacks (and more) in this blog article:
http://mydailyjava.blogspot.no/2013/11/cglib-missing-manual.html
Related
I'm trying to cache the db calls for Yii2 exists validation, but can't work out where to initiate it.
Because I'm using a multi-model form with a lot of relations, the overhead is getting a little too much.
Any ideas?
You'd better not. Actually, there is an issue on Yii2 official Github project where one of the framework's core developers, Alexander Makarov aka #samdark, explains why caching ExistValidator is a bad idea:
Exist validation isn't the kind of validation to be cached. Each second database may change its state so it should be validated just before it's saved.
This is not supported by Yii, you either have to :
Extend the ExistValidator and implement your caching logic there
Add a custom ActiveQuery class to your model in question and override
the exists() and count() methods
I have written a server side Gapps system, but the UI responsiveness is terrible.
Now (unsuccessfully) trying to switch the basic UI handling to client side handlers.
I have discovered the object model (?) documentation for clientside handlers at:
https://developers.google.com/apps-script/class_clienthandler
The first problem seems to be the limited capabilities in Google Script to define event handlers.
I can find no way to incorporate "if" logic in my client side event handler.
Second problem is the (apparent) in-ability to provide client side (java) global variables.
Is there any alternative to storing client side data other than as text in a label or textbox?
I must be missing some basic concept here as I can find no way to provide a real client side Java module to be available in my Gapps delivered page source.
Any suggestions would be greatly appreciated. The UI for this application is quite complex.
PS - the application demands server side processing for several UI triggers.
Client handlers are meant to do trivial tasks such as notifying the user of some progress while all the hard work is done in server handlers. Please post some code of your attempt so that better suggestions can be offered.
Regarding your second question, I prefer to use CacheService to store variable across handlers. For objects, I convert them to JSON and store them using CacheService
I think client handlers maybe confusing, but they make sense. Perhaps think of the handlers as doing the logic for you already. Instead of writing if-then logic, the client handlers will do the work for you. For example, if you want verify that a user has entered in numbers, and make it possible for the user to submit data if the entry is numbers only, then there is a client handler for that. All you have to do is, for example, have a button activated if the entry is numbers.
As you have seen in the documentation, there are many handlers to handle many situations where if-then statements may have been used.
I will be learning the how to handle data storage over the next few days, but there are a few ways to store data like Script and User Properties, scriptDB, spreadsheetd or using JDBC. Here is the documentation referring to the above storage options (in addition to the cacheservice mentioned by Srik) So, I can't offer any expertise there. Try this link for documentation on data storage:
https://developers.google.com/apps-script/script_user_properties
Sorry for the vague answer, but I hope that gives you a least a hint of the direction you need to go for creating the client handlers.
In Podcast 58 (about 20 minutes in), Jeff complains about the problems of HTML.Encode() and Joel talks about using the type system to have ordinary strings and HTMLStrings:
A brief political rant about the evil of view engines that fail to HTML
encode by default. The problem with
this design choice is that it is not
“safe by default”, which is always the
wrong choice for a framework or API.
Forget to encode some bit of
user-entered data in one single
stinking place in your web app, and
you will be totally owned with XSS.
Believe it. I know because it’s
happened to us. Multiple times!
Joel maintains that, with a strongly-typed language and the right
framework, it’s possible (in theory)
to completely eliminate XSS — this
would require using a specific data
type, a type that is your only way to
send data to the browser. That data
type would be validated at compile
time.
The comments at the blog post mention using static analysis to find potential weaknesses. The transcript Wiki isn't done yet.
Is it possible to implement Joel's suggestion without having a new ASP.NET framework?
Might it be possible to implement it simply by subclassing every control and enforcing new interfaces based on HTMLString? If most people already subclass controls in order to better able to inject site-specific functionality, wouldn't this be fairly easy to implement?
Would it be worth doing this instead of investing in static analysis?
To use HtmlString everywhere, you would essentially have to rewrite every property and method of every web control. System.String is sealed, so you can't subclass it.
An easier (but still very time consuming) approach would be to use control adapters to replace web controls with safe alternatives. In this case, you would subclass each web control and override the Render methods to HTML-encode dynamic content.
I'm starting to use Dojo; this is (essentially) my introduction to AJAX. We have a Java backend (torque / turbine / velocity) and are using the jabsorb JSON-RPC library to bridge Java and Javascript.
What do I need to know? What is the big picture of Dojo and JSON, and what are the nasty little details that will catch me up? What did you spend a couple of days tracking down, when you started with Dojo, that you now take for granted? Thanks for any and all tips.
The first thing to do is get familiar with the Dojo Object Model. JavaScript does not have a class system so the Dojo toolkit has created a sort of "by convention" object model that works rather well but is very different to how it works in Java for example.
The reason I suggest getting familiar with it is so you can dig into the code base whenever you start experiencing issues. The documentation available has improved significantly over the past year, but every now and then I find myself having to work out a bug in my code by learning exactly how the Dojo code involved works.
Another tip is to make use of the custom build feature which will significantly improve performance once your application is ready.
As a general tip on DHTML programming, use firebug (a plug-in for Firefox). It allows JavaScript debugging, DOM inspection, HTML editing in real-time and a whole lot more. I've become totally reliant on it now when I'm working in DHTML!
Good luck!
I too just dove head first into Dojo, they have a good API documentation at http://api.dojotoolkit.org/. Even Dojo Campus has some good examples of the plug ins.
If you ask me O'Reilly's Dojo: The Definitive Guide is the best Dojo book on the market.
I also would like any tips and pointers from the Dojo masters.
Cheers
Make sure documentation you read pertains to as recent a release as possible, since a lot has changed very quickly in the Dojo architecture.
Also a great way to see how some Dojo or Dijit widget is used is to look at the source code for the tests - for example, the DataGrid has poor documentation but the tests show a lot of use cases and configurations.
Sitepen is a good resource for Dojo articles.
Also, read up on Deferred (andDeferredList), as well as hitch() - two extremely flexible and powerful features of Dojo. SitePen has a great article on demystifying Deferreds.
Check out plugd, a collection of Dojo extensions that make some things more convenient or adds some clever functionalities to the language. It's made by one of the core Dojo authors so it's rather reliable. It even brings some jQuery niceties into the framework.
Some more things: look into data stores, they're very useful and a much cleaner way to handle Ajax. DojoX has a lot of nice ones too, just remember that DojoX ranges in how well documented or how experimental the components are. Learn the differences between dojo.byId and dijit.byId, as well as the HTML attributes id versus jsId (again, Sitepen has an article).
A couple of things that caught me when I started writing widgets where:
[Understand what dojoAttachPoint, dojoAttachEvent, containerNode and widgitsInTemplate do][1]
have a firm grasp of closures,
Get your head around deferreds
understand ItemFileReadStore, ItemFileWriteStore and stores in general
You can look at stores like a ResultSet (sort of) as well you can data bind them to widgets.
With these major concepts you can start to put together some compelling applications.
Generally what I do is I build a JavaScript facade around my service calls and then I will scrub the response into a store by attaching the first callback in the facade, that call back converts the results into a store and then returns it. This allows me to not hard bind my services to Dojo constructs (so I can support mobile, etc.) while also retuning the data from the facade in a format that data aware widgets expect.
As well if you are doing Java service development you my want to look into JAX-RS. I started out using JSON-RPC which became JABS-ORB but after working with JAX-RS I prefer it, as it integrates well with JPA-EJB and JAXB.
First read how to configure Dojo in your application. Try to understand basic structure of Dojo like if we are writing dijit.form.Button or dijit/form/Button it means Button.js resides in dijit/form folder. Try to understand require, define, declare modules of Dojo. This is enough to start Dojo Toolkit.
Very important fact, indulge with your own sample project using Dojo.
I'm not looking so much for language-specific answers, just general models for implementing a plugin system (if you want to know, I'm using Python). I have my own idea (register callbacks, and that's about it), but I know others exist. What's normally used, and what else is reasonable?
What do you mean by a plugin system? Does Dependency Injection and IOC containers sounds like a good solution?
I mean, uh, well, a way to insert functionality into the base program without altering it. I didn't intend to define it when I set out. Dependency Injection doesn't look particularly suitable for what I'm doing, but I don't know much about them.
A simple plugin architecture can define a plugin interface with all the methods the plugin ought to implement. The plugin handles event from the application, and can use the application's standard code, model objects, etc. to get things done. Basically the same as an ASP.NET Form does, except that you're overriding rather than implementing.
Nobody taught me this part, and I'm no expert, but I feel: In general a plugin will be less stable than its application, so the application should always be in control and only give the plugin periodic opportunities to act. If a plugin can register an Observer, then calls to the delegate should be tried/caught.
There is a very good episode of Software Engineering Radio, which you may be interested in.
For future reference, I have reproduced here the "Rules for Enablers" (alternative link) given in the excellent Contributing to Eclipse by Erich Gamma, Kent Beck.
Invitation Rule - Whenever possible, let others contribute to your contributions.
Lazy Loading Rule - Contributions are only loaded when they are needed.
Safe Platform Rule - As the provider of an extension point, you must protect yourself against misbehavior on the part of extenders.
Fair Play Rule - All clients play by the same rules, even me.
Explicit Extension Rule - Declare explicitly where a platform can be extended.
Diversity Rule - Extension points accept multiple extensions.
Good Fences Rule - When passing control outside your code, protect yourself.
Explicit API Rule - separate the API from internals.
Stability Rule - Once you invite someone to contribute, don?t change the rules.
Defensive API Rule - Reveal only the API in which you are confident, but be prepared to reveal more API as clients ask for it.
In Python you can use the entry-point system provided by setuptools and pkg_resources. Each entry point should be a function that returns information about the plugin -- name, author, setup and teardown functions, etc.
How about abstract factory? Your base program defines how the abstract concepts interact with each other, but the caller has to provide the implementation.