Granite Data Services 1.2.0 GA (Default branch)


 
Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements Software Releases - RSS News Granite Data Services 1.2.0 GA (Default branch)
# 1  
Old 01-08-2009
Granite Data Services 1.2.0 GA (Default branch)

Granite Data Services (GDS) is an alternative to Adobe LiveCycle (Flex 2) Data Services for J2EE application servers. The primary goal of this project is to provide a framework for Flex 2+/EJB3/Seam/Spring/Guice/Pojo application development with full AMF3/RemoteObject benefits. It also features a Comet-like Data Push implementation (AMF3 requests sent over HTTP) and ActionScript3 code generation tools (Ant task and Eclipse Builder). License: GNU Lesser General Public License (LGPL) Changes:
The Gravity implementation for Tomcat was completely rewritten. JBossWeb, a modified Tomcat included in JBoss 5.0.0 GA, is supported. TopLink and EclipseLink were integrated. A specific security service was added for GlassFish. Seam 2.1 in Tide is supported. Tide for Spring and Tide for EJB improvements were made. The WebCompiler now includes the Flex 3.2 SDK and is able to compile code for Flash 10. Maven artifacts are now available on java.net. Image

Image

More...
Login or Register to Ask a Question

Previous Thread | Next Thread
Login or Register to Ask a Question
Data(3) 						User Contributed Perl Documentation						   Data(3)

NAME
Gimp::Data - Set and get state data. SYNOPSIS
use Gimp::Data; $Gimp::Data{'value1'} = "Hello"; print $Gimp::Data{'value1'},", World!! "; DESCRIPTION
With this module, you can access plugin-specific (or global) data in Gimp, i.e. you can store and retrieve values that are stored in the main Gimp application. An example would be to save parameter values in Gimp, so that on subsequent invocations of your plug-in, the user does not have to set all parameter values again (Gimp::Fu does this already). %Gimp::Data You can store and retrieve anything you like in this hash. It's contents will automatically be stored in Gimp, and can be accessed in later invocations of your plug-in. Be aware that other plug-ins store data in the same "hash", so better prefix your key with something unique, like your plug-in's name. As an example, the Gimp::Fu module uses "function_name/_fu_data" to store its data. This module might use a persistant implementation, i.e. your data might survive a restart of the Gimp application, but you cannot count on this. "Gimp::Data" will try to freeze your data when you pass in a reference. On retrieval, the data is thawed again. See Storable for more info. This might be implemented through either Storable or Data::Dumper, or not implemented at all (i.e. silently fail) ;) PERSISTANCE
"Gimp::Data" contains the following functions to ease applications where persistence for perl data structures is required: Gimp::Data::freeze(reference) Freeze (serialize) the reference. Gimp::Data::thaw(data) Thaw (unserialize) the dsata and return the original reference. LIMITATIONS
You cannot store references, and you cannot (yet) iterate through the keys (with "keys", "values" or "each"). AUTHOR
Marc Lehmann <pcg@goof.com> SEE ALSO
perl(1), Gimp. perl v5.8.0 2001-12-06 Data(3)