Granite Data Services 1.1.0 GA (Default branch)


 
Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements Software Releases - RSS News Granite Data Services 1.1.0 GA (Default branch)
# 1  
Old 10-08-2008
Granite Data Services 1.1.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:
Granite Eclipse Builder is a new Eclipse plugin that automatically runs Gas3 (the GDS ActionScript3 code generator) whenever you create or modify a Java source file. Tide provides a full alternative for the Cairngorm + Flex Data Management Service stack (entity caching, collection paging, and transparent lazy loading). MXML Web Compiler may be deployed in your servlet container, and it will build your MXML and ActionScript3 source code on the fly. 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)