text:
You are looking at historical revision 20342 of this page. It may differ significantly from its current revision.
Using the interpreter
CHICKEN provides an interpreter named csi for evaluating Scheme programs and expressions interactively.
Interpreter command line format
csi {FILENAME|OPTION}
where FILENAME specifies a file with Scheme source-code. If the extension of the source file is .scm, it may be omitted. The runtime options described in Compiler command line format are also available for the interpreter. If the environment variable CSI_OPTIONS is set to a list of options, then these options are additionally passed to every direct or indirect invocation of csi. Please note that runtime options (like -:...) can not be passed using this method. The options recognized by the interpreter are:
- --
- Ignore everything on the command-line following this marker. Runtime options (-:...) are still recognized.
- -i -case-insensitive
- Enables the reader to read symbols case insensitive. The default is to read case sensitive (in violation of R5RS). This option registers the case-insensitive feature identifier.
- -b -batch
- Quit the interpreter after processing all command line options.
- -e -eval EXPRESSIONS
- Evaluate EXPRESSIONS. This option implies -batch and -quiet, so no startup message will be printed and the interpreter exits after processing all -eval options and/or loading files given on the command-line.
- -p -print EXPRESSIONS
- Evaluate EXPRESSIONS and print the results of each expression using print. Implies -batch and -quiet.
- -P -pretty-print EXPRESSIONS
- Evaluate EXPRESSIONS and print the results of each expression using pretty-print. Implies -batch and -quiet.
- -D -feature SYMBOL
- Registers SYMBOL to be a valid feature identifier for cond-expand and feature?.
- -h -help
- Write a summary of the available command line options to standard output and exit.
- -I -include-path PATHNAME
- Specifies an alternative search-path for files included via the include special form. This option may be given multiple times. If the environment variable CHICKEN_INCLUDE_PATH is set, it should contain a list of alternative include pathnames separated by ;.
- -K -keyword-style STYLE
- Enables alternative keyword syntax, where STYLE may be either prefix (as in Common Lisp) or suffix (as in DSSSL). Any other value is ignored.
- -n -no-init
- Do not load initialization-file. If this option is not given and the file ./.csirc or $HOME/.csirc exists, then it is loaded before the read-eval-print loop commences.
- -no-parentheses-synonyms STYLE
- Disables list delimiter synonyms, [..] and {...} for (...).
- -no-symbol-escape
- Disables support for escaped symbols, the |...| form.
- -w -no-warnings
- Disables any warnings that might be issued by the reader or evaluated code.
- -q -quiet
- Do not print a startup message. Also disables generation of call-trace information for interpreted code.
- -r5rs-syntax
- Disables the Chicken extensions to R5RS syntax. Does not disable non-standard read syntax.
- -s -script PATHNAME
- This is equivalent to -batch -quiet -no-init PATHNAME. Arguments following PATHNAME are available by using command-line-arguments and are not processed as interpreter options. Extra options in the environment variable CSI_OPTIONS are ignored.
- -sx PATHNAME
- The same as -s PATHNAME but prints each expression to (current-error-port) before it is evaluated.
- -ss PATHNAME
- The same as -s PATHNAME but invokes the procedure main with the value of (command-line-arguments) as its single argument. If the main procedure returns an integer result, then the interpreter is terminated, returning the integer as the status code back to the invoking process. Any other result terminates the interpreter with a zero exit status.
- -setup-mode
- When locating extensions, search the current directory first. By default, extensions are located first in the extension repository, where chicken-install stores compiled extensions and their associated metadata.
- -R -require-extension NAME
- Equivalent to evaluating (require-extension NAME).
- -v -version
- Write the banner with version information to standard output and exit.
Writing Scheme scripts
Since UNIX shells use the #! notation for starting scripts, anything following the characters #! is ignored, with the exception of the special symbols #!optional, #!key, #!rest and #!eof.
The easiest way is to use the -script option like this:
% cat foo #! /usr/local/bin/csi -script (print (eval (with-input-from-string (car (command-line-arguments)) read)))
% chmod +x foo % ./foo "(+ 3 4)" 7
The parameter command-line-arguments is set to a list of the parameters that were passed to the Scheme script. Scripts can be compiled to standalone executables (don't forget to declare used library units).
CHICKEN supports writing shell scripts in Scheme for other platforms as well, using a slightly different approach. The first example would look like this on Windows:
C:>type foo.bat @;csibatch %0 %1 %2 %3 %4 %5 %6 %7 %8 %9 (print (eval (with-input-from-string (car (command-line-arguments)) read)))
C:>foo "(+ 3 4)" 7
Like UNIX scripts, batch files can be compiled. Windows batch scripts do not accept more than 8 arguments.
Since it is sometimes useful to run a script in the interpreter without actually executing it (for example to test specific parts of it), the option -ss can be used as an alternative to -script. -ss PATHNAME is equivalent to -script PATHNAME but invokes (main (command-line-arguments)) after loading all top-level forms of the script file. The result of main is returned as the exit status to the shell. Any non-numeric result exits with status zero:
% cat hi.scm (define (main args) (print "Hi, " (car args)) 0) % csi -ss hi.scm you Hi, you % csi -q #;1> ,l hi.scm #;2> (main (list "ye all")) Hi, ye all 0 #;3>
Toplevel commands
The toplevel loop understands a number of special commands:
- ,?
- Show summary of available toplevel commands.
- ,l FILENAME ...
- Load files with given FILENAMEs
- ,ln FILENAME ...
- Load files and print result(s) of each top-level expression.
- ,p EXP
- Pretty-print evaluated expression EXP.
- ,d EXP
- Describe result of evaluated expression EXP.
- ,du EXP
- Dump contents of the result of evaluated expression EXP.
- ,dur EXP N
- Dump N bytes of the result of evaluated expression EXP.
- ,e FILENAME
- Runs an external editor to edit the given FILENAME (see below for more information).
- ,h
- Shows all previously evaluated expression results.
- ,ch
- Clears stored expression results of previously evaluated expressions.
- ,exn
- Describes the last exception that occurred and adds it to the result history (it can be accessed using the # notation).
- ,c
- Show call-trace items of the most recent error
- ,f N
- Select call-trace item with the given number, where the number 0 indicates the last item in the trace
- ,g NAME
- Returns the value of the local variable with the given name (which may be a symbol or string)
- ,q
- Quit the interpreter.
- ,r
- Show system information.
- ,s TEXT ...
- Execute shell-command.
- ,t EXP
- Evaluate form and print elapsed time.
- ,x EXP
- Pretty-print macroexpanded expression EXP (the expression is not evaluated).
You can define your own toplevel commands using the toplevel-command procedure:
toplevel-command[procedure] (toplevel-command SYMBOL PROC [HELPSTRING])
Defines or redefines a toplevel interpreter command which can be invoked by entering ,SYMBOL. PROC will be invoked when the command is entered and may read any required argument via read (or read-line). If the optional argument HELPSTRING is given, it will be listed by the ,? command.
Getting error information
Interpreted code has some extended debugging information available that can be used to locate errors and obtaining information about the lexical environment that was effective at the point of error. When an error occurs in an evaluated expression, a "call trace" is printed - the list of calls up to the error location. Note that this does not follow a stack model: it is merely a list of recently made procedure calls where the last one in the list is (probably) the call of whatever procedure was executing before the error happened. You can use the ,c command to show the call-trace of the last error. Depending on whether compiled or interpreted code was executing and how much debugging information is available, the call trace shows trace-buffer entries of the following shape:
<frame-number>:<environment?> <mode> <procedure-name> <form>
<frame-number> gives the number of the call-trace entry, counting from zero and beginning with the most recent entry. If a [] follows the frame-number, then this frame contains the lexical environment in effect when that procedure call took place. <mode> is optional and is either <syntax> or <eval> indicating whether this trace-buffer entry represents a syntax-expansion or an evaluation and is not given for compiled code. <form> is also only available for interpreted code and shows the procedure call expression, possibly following the name of the procedure containing the call expression.
If the trace-buffer entry contains lexical environment information than the complete environment of the call site is shown.
Use ,f to select a frame by number, if you want to inspect the lexical environment of an earlier frame. The ,g command lets you retrieve the value of a local or lexical variable from the currently selected frame. Note that the variables are renamed to simplify the variable lookup done internally by the interpreter.
Running an external editor
The ,e command runs the editor given by:
- The parameter editor-command which should return a string naming an external editor and defaults to #f, which means no editor is currently selected (so the following alternatives are tried).
- The contents of the environment variables EDITOR or VISUAL.
- If the environment variable EMACS is set, the editor chosen is emacsclient.
- As a last resort, vi is used.
History access
The interpreter toplevel accepts the special object #[INDEX] which returns the result of entry number INDEX in the history list. If the expression for that entry resulted in multiple values, the first result (or an unspecified value for no values) is returned. If no INDEX is given (and if a whitespace or closing paranthesis character follows the #, then the result of the last expression is returned. Note that the value returned is implicitly quoted.
set-describer![procedure] (set-describer! TAG PROC)
Sets a custom description handler that invokes PROC when the ,d command is invoked with a record-type object that has the type TAG (a symbol). PROC is called with two arguments: the object to be described and an output-port. It should write a possibly useful textual description of the object to the passed output-port. For example:
#;1> (define-record-type point (make-point x y) point? (x point-x) (y point-y)) #;2> (set-describer! 'point (lambda (pt o) (print "a point with x=" (point-x pt) " and y=" (point-y pt)))) #;3> ,d (make-point 1 2) a point with x=1 and y=2
Auto-completion and edition
On platforms that support it, it is possible to get auto-completion of symbols, history (over different csi sessions) and a more feature-full editor for the expressions you type using the http://wiki.call-cc.org/eggref/4/readline egg by Tony Garnock Jones. It is very useful for interactive use of csi.
To enable it install the egg and put this in your ~/.csirc file:
(use readline regex) (current-input-port (make-gnu-readline-port)) (gnu-history-install-file-manager (string-append (or (getenv "HOME") ".") "/.csi.history"))
The interpreter csi internally requires some routines from the ports and extras library units and loads them automatically on startup. These libraries are not automatically loaded in compiled code, so there is an inconsistency between code that is executed in csi versus code that is compiled and executed.
Previous: Using the compiler
Next: Supported language


text:
|Número de publicación
|Tipo de publicación
|Número de solicitud
|Fecha de publicación
|19 Ene 2010
|Fecha de presentación
|27 Feb 2004
|Fecha de prioridad
|28 Feb 2003
|También publicado como
|Número de publicación
|Daryl B. Olander, Richard Feit, Edward K. O'Neil, Timothy Breeden, Scott Musson, Christopher Jolley, Thomas A. Cook, Sathyanarayana Giridhar, Jason Howes, Douglas Dew, Fernand Galiana, Robert Bergman, Brodi Beartusk, Purushotham Babu Naidu
|Cesionario original
|Bea Systems, Inc.
|Exportar cita
|BiBTeX, EndNote, RefMan
|Citas de patentes (27), Otras citas (17), Citada por (19), Clasificaciones (19), Eventos legales (7)
|Enlaces externos: USPTO, Cesión de USPTO, Espacenet
This application claims priority from the following application, which is hereby incorporated by reference in its entirety:
U.S. application Ser. No. 60/450,991, FRAMEWORK FOR A PERSONALIZED PORTAL, Inventors: Daryl Olander, et al., filed on Feb. 28, 2003.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright right whatsoever.
This application is related to the following co-pending applications which are each hereby incorporated by reference in their entirety:
U.S. application Ser. No. 10/788,803, Inventors: Scott Musson, et al., filed on Feb. 27, 2004, SYSTEM AND METHOD FOR CONTAINING PORTLETS.
U.S. application Ser. No. 10/788,530, Inventors: Scott Musson, et al., filed on Feb. 27, 2004, METHOD FOR ENTITLING A USER INTERFACE.
U.S. application Ser. No. 10/788,876, Inventors: Scott Musson, et al., filed on Feb. 27, 2004, METHOD FOR PROVIDING A GRAPHICAL USER INTERFACE.
U.S. application Ser. No. 10/789,137, Inventors: Daryl B. Olander, et al., filed on Feb. 27, 2004, METHOD FOR UTILIZING LOOK AND FEEL IN A GRAPHICAL USER INTERFACE.
U.S. application Ser. No. 10/788,801, Inventors: Scott Musson, et al., filed on Feb. 27, 2004, METHOD FOR PORTLET INSTANCE SUPPORT IN A GRAPHICAL USER INTERFACE.
U.S. application Ser. No. 10/789,135, Inventors: Daryl B. Olander, et al., tiled on Feb. 27, 2004,CONTROL-BASED GRAPHICAL USER INTERFACE FRAMEWORK.
U.S. application Ser. No. 10/789,140, Inventors: Daryl B. Olander, et al., filed on Feb. 27, 2004, SYSTEM AND METHOD FOR DYNAMICALLY GENERATING A GRAPHICAL USER INTERFACE.
U.S. application Ser. No. 10/789,137, Inventors: Daryl B. Olander, et al., filed on Feb. 27, 2004, METHOD FOR PROPAGATING AND FEEL IN A GRAPHICAL USER INTERFACE.
Developing graphical user interfaces (GUIs) for distributed applications such as web portals can present many challenges. Not only do end-users expect to customize the content a given GUI presents to them, they might also expect to customize the look and feel of the GUI. Such customization can be coarse-grained, as in changing an overall color scheme, but they can also be fine-grained wherein an end-user may desire to change the textures, arrangement, behaviors and other characteristics of the GUI. This presents many design challenges, especially if such a GUI is deployed in a clustered, multi-threaded runtime environment.
The present disclosure relates generally to graphical user interface development.
The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to "an" or "one" embodiment in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
Within page 16 is display area 10, which includes portlets (18, 30, 32) and other elements. A portlet is an application that manages its own GUI. Portlets can communicate with each other and with other software and hardware components (e.g., Enterprise Java Beans™, Java™ Beans, servlets, applets, etc.). The Java™ programming language, its libraries, environment, and toolkits are available from Sun Microsystems, Inc. of Santa Clara, Calif. The other software and hardware components may be part of the same execution environment as the portlet or may be in a different execution environment. In one embodiment, a portlet can be implemented with JavaServer Pages™. By way of a non-limiting example, portlet 30 displays real-time stock ticker information. A user could configure such a portlet to display certain stocks, for example. In another embodiment, the user can select a given stock displayed in portlet 30 and receive more detailed information, such as the price history, price to earnings ratio, etc.
Portlet 30 can handle user input and responding accordingly. Portlet 32 displays up-to-date information pertaining to a user's checking accounts. Likewise, portlet 32 could provide detailed information on transactions if the user were to select an account. Advertisement portlet 18 displays an advertisement that could be directed specifically to the current user based on demographics or other information. For instance, if a user had an outstanding home loan in good standing, the advertisement could be for a home equity loan. Likewise, if the user had an appropriate amount in a savings account, the advertisement could be for a new car loan. Static area 14 contains text or an image with text.
At the top of the taxonomy, there can be one or more web applications 200. A web application represents a collection of resources and components that can be deployed as a unit in one or more web/application servers. In one embodiment, a web application can represent a J2EE (Java 2 Platform, Enterprise Edition) Enterprise Application. In various embodiments, a web application can contain one or more controls 202 representing one or more portals. From an end-user perspective, a portal is a website whose pages can be navigated. From an enterprise perspective, a portal is a container of resources and functionality that can be made available to end-users. Portals can provide a point of access to applications and information and may be one of many hosted within a web/application server. In one embodiment, a portal can be a J2EE application consisting of EJB (Enterprise Java Bean) components and a set of Web applications. In another embodiment, a portal can be defined by an XML (Extensible Markup Language) file. The portal file can contain all of the components that make up that particular instance, such as booklets, pages, portlets, and look and feel components.
A GUI can contain one or more desktop controls 204. A desktop control in turn can contain one or more personalized views or user views (not shown). A user can have one or more personalized user views of a desktop. In one embodiment, a user view can result from customizing the layout, content, number, and appearance of elements within a desktop. A default user view can be provided for users who have not yet customized a desktop. A desktop's appearance can be determined by a Look and Feel control 210. The look and feel control can contain a skin component 220 and a skeleton component 222. Skins can provide the overall colors, graphics, and styles used by all components in a desktop interface. In one embodiment, skins can include collections of graphics and cascading style sheets (CSS) that allow changes to be made to the look and feel of the GUI without modifying other components directly. References to images and styles can be made in the skin rather than being hard-coded into a GUI definition. A look and feel component can provide a path to a skin directory to be used.
The look and feel file can also provides a path to the skeleton directory to be used. Every type of component, from a desktop to a portlet's title bar, can have an associated JSP (Java ServerPages™) file, called a skeleton file, that renders it. For example, each desktop uses a skeleton file called shell.jsp that simply provides the opening and closing <HTML> (Hypertext Markup Language) tags to render the desktop. A portlet title bar, on the other hand, can have a skeleton file called titlebar.jsp that is more complex. It contains Java calls to various windowing methods in the API, references the button graphics to use on the title bar, and determines the placement of title bar elements with an HTML table definition.
A desktop also can contain a booklet control 206. A booklet control represents a set of pages linked by a page navigator (menu 214) having a user selectable graphical representation (e.g., a series of tabs wherein each tab corresponds to a different page, a series of buttons, a menu, or other suitable means.) A booklet can provide an indication of the currently selected page through visual clues such as highlighting a currently selected tab, displaying text and/or graphics to indicate the current page, etc. Booklets can be nested to n levels. A booklet can optionally include a theme control 212. In one embodiment, a theme control represents a subset of a skin component and can provide a way of using a different set of styles for individual desktop components. The booklet control can also contain other booklets 216.
A shell control 208 can render anything surrounding the booklet 206 in the desktop 204. For example, a shell control might render a desktop's header and footer. These areas usually display such things as personalized content, banner graphics, legal notices, and related links.
A booklet also contains zero or more page controls 218. A page control can represent a web page in an embodiment. A page is an area of a GUI upon which other elements having GUIs, such as booklets and portlets, can be placed. Pages can also contain booklets and other pages, and can be identified/navigated to by a control such as a menu 214. A page control can also hold a theme control 224 and a layout control 226. A layout control determines the physical locations of portlets and other elements on a page. In one embodiment, a layout is can be implemented as an HTML table.
A layout can contain a placeholder control 228 which is comprised of individual cells in a layout in which portlets are placed. A placeholder can contain zero or more booklets 232 and zero or more portlets 230. A portlet is a self-contained application that can render its own GUI. A portlet is a self-contained application that is responsible for rendering its own content on a page. By way of a non-limiting example, a portlet might be a display of current news headlines, wherein if a user selects a headline the portlet retrieves and the underlying story and displays it for the user. Portlets can communicate with other portlets and with back-end processes such as legacy software, databases, content management systems, enterprise business services, etc. In addition, multiple instances of a portlet can execute simultaneously. A portlet can also contain a theme 234.
A control tree can represent a particular instance of the control taxonomy. In one embodiment, each node in the control tree can be a subclass of a Control class in an object-oriented paradigm. A control tree can be created with both statically created controls and dynamically created controls. Statically created controls are created during a construction (or "wire-up") phase of the control tree and, in one embodiment, can be based on static markup. Dynamically created controls are created during a control tree lifecycle, many times in reaction to state, context, and events. Both kinds of controls can create content either dynamically (e.g., by binding to a database table) or statically (e.g., by containing a literal string).
Controls within a control tree can have unique names. In addition, controls can have local names that are qualified into a scope. This can allow for controls to be searched for based upon their "local" name within a naming scope. In one embodiment, the system can use a control's unique name for identifying it in operations such as saving and restoring state during the cycle of HTML postbacks to the page. Postback occurs when a form on a page targets the same page. When the form is submitted, the second request for the page is called a postback. The postback allows the page to handle changes made to data and raise events before either redirecting to a new page or simply displaying the same page again. In one embodiment, multiple control scopes can be provided as described in Table 1.
Object Scopes in an Embodiment
An object is accessible for the life of the request.
An object is accessible across subsequent requests
to a page. In one embodiment, a page has a
lifetime that can include a postback cycle.
An object is accessible for the life of the session. (This is
available for protocols that support session.)
An object is accessible within a named scope
defined by a webflow. A Webflow is a set of
states that control navigation
from one web page to another.
An object is accessible globally
within the application.
In one embodiment, many of the classes can be sub-classed to provide specializations and custom features. It will be apparent to those skilled in the art that many more such classes are within the scope and spirit of the present disclosure. Table 2 provides an overview of classes in one embodiment.
Framework Controls in an Embodiment
The basic framework building block. The base Control class
defines a set of services available to all controls. This class
defines and provides a set of services to subclasses including
lifecycle, naming, and child management.
A lifecycle driver will drive the control-tree through a well
defined set of states. For a control, the lifecycle is defined by a
set of methods representing stages in the lifecycle. A control
can override methods of the lifecycle in order to provide
specialized behavior. For example, most controls will override
beginRender to render its specific representation to an output
stream. The stages provide well defined places to acquire
resources, manage state, raise events, render themselves, etc.
Most lifecycle stages consist of two methods that are called by
the lifecycle driver. The naming pattern of the two methods is
Xxxx and fireXxxx. The Xxxx method is overridden by
subclasses to specialize the lifecycle stage. The fireXxxx
method is overridden if a control wants to change how the event
associated with the lifecycle stage is fired.
Defines methods called during the control's lifecycle. There are
two methods for most lifecycle events. The lifecycle method
xxx is called first to provide the lifecycle service for the control.
Then an onXxx method is called to raise an event. In one
embodiment, all of the lifecycle stages prior to rendering raise
events through the onXxx method.
The Control and the NamingScope interface interact to provide
support for uniquely naming a control within a tree. Unique
names are generated automatically when controls are added to
an existing control-tree. Unique names are used for state
management. Controls have three types of names:
Id - This is a user assigned value that should be unique within a
name scope.
ScopeId - This is a generated name that is unique within a
scope. It is either the Id or a generated name.
UniqueId - This is the globally unique name of the control.
This name is typically used to identify state and identify the
control within a HTML Form.
Context is an abstract class providing services to controls in the
tree. In one embodiment, these services are protocol-
independent. It is the container's responsibility to create the
context object. The container can create an object that
subclasses Context and provides container aware controls with
additional services such as information about the framework and
or protocol.
By way of a non-limiting example, a container can be a servlet
providing a framework. The Context can contain both HTTP-
specific information and web application-specific information.
A Portlet control that is portal-aware can cast the Context into
the subclass and access these services. Well-designed controls,
which are aware of one or more containers, can be written to
work or fail gracefully when they are used within the context of
the generic Context.
Context provides the following services:
Access to the Abstract Data Layer - Context will provide an
object implementing the interface providing an abstract data
Request Type - The Context contains properties indicating what
type of request is happening such as "new request", "postback",
Request Information - The Context provides information that
comes from the request such as request parameters, requested
URL, etc. This information may be unavailable for protocols
that don't support it.
Generic Services - The context allows controls to access and
register as service providers to other controls. For example, a
StyleBlock control may register as the StyleHandler object that
will create a single style sheet for an output HTML document.
Other controls may push style definitions into the StyleHandler.
These services will typically be used by a set of framework
aware controls and will support things such as styles, URL
rewriting, etc.
Renderer is an interface that allows a class to be created and
which acts as a rendering proxy for a control. A control has
rendering methods allowing the control to output its
representation into a stream. There are two primary methods for
rendering; beginRender( ) and endRender( ). Default rendering
can be overridden by setting a control's renderer by providing
an object implementing the Renderer interface.
In one embodiment, a GUI is rendered in response to a request (e.g., an HTML request originating from a web browser). In step 300, a process (e.g., a web/application server or other suitable process) can accept the request and map it to a control tree factory. In step 302, the identified factory can be used to generate a control tree representing the GUI. In step 304, the control tree can be evaluated based on the contents of the request. In doing so, the control tree can be driven through a sequence of lifecycles that allow for individual controls in the tree to, by way of a non-limiting example, process the request, interact with each other and a context provided by the container, and produce a response. Finally, in step 306 the process can provide a response to the sender of the request. In one embodiment, this response can contain output for GUI rendering (e.g., HTML or other suitable GUI description) from one or more controls.
In one embodiment a container (not shown) can run the control tree through a sequence of one or more lifecycles by employing the services of an interchangeable lifecycle driver (not shown). In one embodiment, a control or a container can customize the lifecycle. Customization can include removing and/or reordering defined lifecycle stages and/or adding new stages. All of the controls in the control tree can participate in the lifecycle, but do not have to. The purpose of the lifecycle is to advance the control tree though a set of states. These states permit controls to obtain their state and resources, raise and handle events, save their state, communicate with other controls, render themselves, and free resources. The lifecycle is external to the control tree and can be provided by the container. This allows for easy modification of the lifecycle.
In one embodiment, controls can register to raise and catch events to perfect inter-control communication. An event mechanism allows controls to specify (or register for) events that they will raise and/or listen for. In one embodiment, this can be accomplished with two methods. A method named "xxxx" represents the lifecycle method itself and is usually sub-classed to provide specialized behavior for the control. A method named "fireXxxx" can be invoked to cause an event notification that the lifecycle method xxxx has run on the control. This method can be overridden to provide specialization of event firing. By way of a non-limiting example, a control could suppress firing of an event by overriding it and doing nothing. When an event is raised, all controls that have registered to receive it will be given an opportunity to handle the event (e.g., through a call-back mechanism). There is no limit on the number of events that can be raised or caught. By way of a non-limiting example, a form control could raise an event when a user enters text in a text field of a GUI representation of the form. This event could be caught by a button on the same page as the form. The button could then un-dim itself based on a determination of whether a user entered a valid character sequence into the form.
Controls can be dynamically added to the tree at any stage of the lifecycle up until a pre-render stage. When controls are added to an existing tree dynamically, these new controls can participate in the full lifecycle. In one embodiment, a lifecycle catch-up process can drive the new controls through the lifecycle until they catch-up to the current stage. All lifecycle stages before the rendering stage can raise events. In one embodiment, a container can implement the lifecycle stages illustrated in Table 3.
Lifecycle Stages in an Embodiment
Allows a control to perform initialization.
Load State
Load previously saved state from the request. This state
represents the GUI state of the page.
Create Child Controls
Stage used to create child controls.
Obtain external resources necessary for processing the
request. If the request is a postback, at this point the
controls' states match their states in the
client's view, i.e., saved state has been restored and
postback data has been used to update controls with new values.
Raise Events
This is a two phase stage where controls first indicate
they want to raise events and then all controls who
indicated this are allowed to raise events.
This is the final stage before the rendering stages. At this
point the tree should be stable and all events processed.
Save State
This stage is the first stage in rendering. All controls that
want to save their states are given the opportunity to do
so. Any changes to controls after this point cannot affect
the saved state. This is the page specific GUI state.
Application level state is managed at a different level.
This is the stage where controls create their GUI
representations and control how their children are
This stage allows the control to free resources obtained in
Any final cleanup can be done.
A request 410 can be mapped to a control tree factory 402 by container 400. In one embodiment, the container use "wire-up" service 404 in the factory which will cause the factory to return the root of a control tree. In one embodiment, the generation of the control tree is based in part on the request. The control tree (not shown) produced by control tree factory can be a page level object or can become a sub-tree of a larger control tree. The control tree factory is independent of container 400 and can be accessed from multiple containers. In one embodiment, the control tree factory can make modifications to the tree such as replacing the default rendering or state methods for a control, including for the page itself. In one embodiment, the container can associate a Context object 408 with the control tree root. A base Context class can provide generic services to controls in a control tree and can be protocol independent. Generally speaking, a container can be associated with both a specific protocol and application framework. However, the container can also provide a subclass of Context to expose protocol and application-specific objects and services.
In one embodiment, the framework can support JSP as a page description language. The control tree produced by such an implementation can allow for full use of JSP features such as tag extensions, scriptlets and expressions. By way of a non-limiting example, a servlet mapped to the extension ".jsp" can handle all JSP pages 502 mixing JSP and controls and can act as a container. The servlet can provide a request 516 to factory 500, which will generate a control tree. The factory can use a JSP parser variant 504 to create a metadata representation of a control tree 508. The parser variant captures the hierarchy of controls and for each control it recognizes, it can also capture information about the properties, events, and model binding that have values set in the page description. The parser variant can also capture template text in the JSP page and create metadata representing the template text as literal controls. By way of a non-limiting example, tag library extensions can represent controls in the JSP page. A standard JSP compiler 506 can also process the .JSP page and produce a .JSP page implementation class 510 that can be used to render JSP in concert with the control tree.
A class 514 is created to process the metadata. The class provides a service 512 that can be used to instantiate a control tree on behalf of a container. If the JSP page contains JSP-specific features, the service can make use of an inner class that implements a Renderer interface (not shown). The Renderer interface can act as a proxy for rendering of the control tree. In one embodiment, this proxy defers to a _jspService( ) method found in the JSP page implementation class. The Renderer interface treats the page implementation class as a servlet and drives it through the lifecycle, providing it a servlet context and other things needed. Tag extensions can be mapped into the control tree during the render lifecycle. The variant parser can create literal controls in the control tree for instances of template data found in the JSP page. In one embodiment, if a JSP page contains only controls and template data, the _jspService( ) method does not to be invoked.
Referring to
In one embodiment, JSP container 700 drives the control tree instantiation process with help from a tag library extension that acts as a container of state set on tag attributes that can be pushed into control instances that the tags create. In one embodiment, this process can be demarcated in a page description file 702 with a pair of tags 704 and 712. One or more tags 706 can locate the metadata description of the control tree and create the control tree. Other tag(s) 708 can create a context for the control tree and drive it through its lifecycle 710 to the render stage. The container then allows its body content to render the page. Then, tag 712 can drive the final portions of the lifecycle.
JSP input can also be supported. One embodiment can utilize a backing file in addition to the JSP file. The backing file can be a Java class that lives beside the JSP file and contains two types of customizations: 1) overloaded method and event handling logic; and 2) declarations for all controls inside the control tree that have an identification property set. Code can be written in overloaded methods such that an event handler has access to these controls. The JSP page extends a Backing class, which gives the wire-up method the ability to use the JSP implementation class as the root of the control tree. The wire-up method can also insure that the declared controls are initialized and that event handlers are wired up. In one embodiment, the variant JSP parser may produce the backing file within the code generated to wire up the tree. The wire up can initialize variables in the backing file and wire-up handlers.
In yet another embodiment, all input can be derived from a JSP file. Code to handle events can be declared (e.g., "<%! . . . %>") directly in the JSP file as a method. The wire-up process would insure that the proper method would be called. The same could be done for the control variable declarations. In many cases, these declarations would not be written and a Model object would act as an event handler. Thus, one can override methods on control and handle events in this way.
Referring to
Controls have the ability to persist state across HTTP (Hypertext Transfer Protocol) requests. A state management API can be provided to give each control in the tree the ability to persist itself before rendering an HTTP response. When an HTTP submit to the same page is received, this saved state can be used to re-hydrate or restore the control tree from its persisted state. Thus, the same state can be maintained across different instances of the same control tree with minimal effort to the control author. Controls can be persisted using a state management persistence mechanism.
The Context object can provide access to an interface providing an ADL (Abstract Data Layer). The ADL can provide a named binding to objects within a specific scope support for object activation and creation, caching, named access, etc. The framework can define a binding language that can be used to bind properties on controls to properties on objects.
In one embodiment, state management can be implemented behind a pair of interfaces: ClientStateWriter and ClientStateReader. The ClientStateWriter provides an interface that a control can use to write any primitive type or object into state management. By way of a non-limiting example, the following methods can be exposed:
public void writeByte(byte b);
public void writeShort(short s);
public void writeString(String s);
public void writeObject(Object o);
At a particular stage in the control tree lifecycle, the control has the opportunity to save its state. In one embodiment, when a control calls a saveState( . . . ) method, the control receives a ControlStateWriter object into which it can write its state. A control's contract with state management is that on the page's next submit, the control can re-read this state using the corresponding loadState( . . . ) lifecycle method. A control can read the state in the same order in which the state was written. By way of a non-limiting example, state can be read by using methods defined on the ControlStateReader interface such as:
public byte readByte( );
public short readShort( );
public String readString( );
public Object readObject( );
A control is aware only that it is receiving an interface against which to save any of its state. How the state is actually written and where it is stored are left as implementation details to the implementer of the state management. One approach to state management may be to write the state into a web page and have the state submitted whenever a form from the page is submitted. This approach suffers from problems when the amount of state that is written to the browser is large, though it may keep the server from having to track large and expensive user session objects. The flexibility of this embodiment is that a web application and even a page can be configured to use a particular state management policy for state that a control tree has written into a ControlStateWriter. The resulting state could be stored in the client, as mentioned, the database, a cache system, or even the user session. In one embodiment, state can be written to a page as a hidden field found in a form.
In one embodiment, a state management implementation consists of a ControlStateWriter that writes to a byte array that is Base64 encoded and written to the browser in an input tag within a form tag. When the form is submitted, the state string is contained in the request data and is used to create a ControlStateReader that contains the data for each control. ControlStateReaders can also be chained such that the container can find a ControlStateReader for a particular control instance from any number of locations that may be in a state reader chain. A reader chain is specified with a list of implementations in an external XML file that is parsed at runtime.
The organization of controls in a tree can also be persisted. In one embodiment, it is assumed that some language (e.g., JSP, XML, etc.) can be used to describe the control tree and that control tree factory can process this language and return a representation of the tree. In one embodiment, the language can describe metadata about the control tree, the hierarchical relationship between controls, property/value pairs for controls in the tree, and event handling. In one embodiment, the language can be manipulated as a stream by the framework. A so-called streaming control tree can plug into the framework by implementing a control tree factory.
In one embodiment, a streaming control tree factory creates a control tree from an XML Stream. By way of a non-limiting example, the XML stream may be obtained from multiple sources including the file system, a database, a dynamically constructed Document Object Model (DOM) Tree, etc. In one embodiment, a streaming control tree factory first parses an XML document representation of a control tree into a DOM Tree. The XML document can conform to one or more known schemas which define how a control tree is described. The DOM tree is then processed to create a representation of the control tree. When the streaming control tree factory is asked for an instance of the control tree, the factory will create a new instance of the control tree from the representation.
In one embodiment, after an initial control tree is created, Java Serialization can be used to obtain a serialized (or streamed) view of the control tree. When an instance of the streaming control tree is requested from a control tree factory, the serialized view is deserialized. In another embodiment, Java™ code generation can be used to create a class that will create the control tree. In this embodiment, Java™ code is that knows how to create and initialize the control tree is generated. When a streaming control tree is requested from the factory, the compiled version of Java™ code is executed to obtain the control tree.
In order to increase the performance of controls that use long-running resources such as EJBs (Enterprise Java Beans), database accesses or external site content, portions of the control lifecycle can be modified to support running subtree lifecycles in parallel. By way of a non-limiting example, assume there are two controls, A and B, each which rely on using a long-running resource in their lifecycles. Standard serial lifecycle traversal over these controls will result in total run time greater than the sum of the run times of the long-running resources. However, if these two controls could be run in separate threads, it is likely that the overall runtime will be less than in the serial case.
In one embodiment, two variations of multithreading are enabled for controls: preRender multithreading and render multithreading. PreRender multithreading is the simplest of these, while render multithreading is probably the more useful for the most common performance needs (e.g., where external site content is included into the final control tree output).
In one embodiment, a multithreaded foundation is shared between the two multithreading variations. This foundation includes a ControlTreeWalkerPool class. This class is used to spawn off ControlTreeWalker invocations to process each thread of processing control. Additionally, this class can perform accounting and synchronization of the spawned workers. When a new worker is created and dispatched, a count can be incremented of the workers still performing tasks. At the completion of a task, a worker can decrement the count. The main calling thread can then use the ControlTreeWalkerPool to wait until all workers have completed their tasks before continuing processing a Lifecycle run.
The ControlTreeWalkerPool can internally use instances of WalkerWorkers, specialized to the type of multithreading to be done. A factory can be used to instantiate a specific type of WalkerWorker, after which a set of thread context information is gathered, including the ContextClassLoader and Subject associated with the mainline thread. The assignment and execution of the tasks for a WalkerWorker is performed using the Weblogic kernel facilities for running ExecuteRequests on threads obtained from ExecuteThreadPools. In this case, the each WalkerWorker implements the ExecuteRequest interface, allowing it to be dispatched to a WLS ExecuteThread.
Once a WalkerWorker has been dispatched to an ExecuteThread, it performs two additional steps before the actual control tree walk is performed. First, a ContextClassLoader is transferred to the ExecuteThread. Then, a WalkerWorkerPrivilegedAction class object, which implements a PrivilegedExceptionAction, is created and invoked on the current thread using a Subject saved from the mainline thread. This privileged action is then used to perform a Security.runAs( ) method so that the WalkerWorker task is performed with the same user security privileges as in the mainline thread. At this point, code specific to the type of WalkerWorker is executed via a default pattern, where concrete WalkerWorker classes implement the Walker Worker method execute Walker Worker.
Multithreaded preRender is useful in cases where a control can perform the long-running portion of its processing without the need to immediately render its results into the response. This might include cases where EJB's are called or long-running computation is done, the results of which are then saved for use in the render lifecycle phase. The multithreaded preRender implementation is composed of two pieces: a class called LifecycleWorker, which extends WalkerWorker, and a modified version of the ControlTreeWalker's walkRecursive( ) method called walkRecursivePreRender( ).
In one embodiment, the LifecycleWorker class is actually a generic WalkerWorker that can perform a control sub-tree walk for any arbitrary lifecycle stage. It simply captures the control tree root and the lifecycle stage as arguments to its contructor, then uses a new ControlTreeWalker instance to perform a walk on the sub-tree root during the threaded execution.
In one embodiment, the walkRecursivePreRender method is a modified version of ControlTreeWalker.walkRecursive, adding the ability to look for controls that are marked as preRenderForkable and use the ControlTreeWalkerPool to dispatch workers for a subtree. Note that only the first subtree encountered depth-wise is dispatched in a multithreaded manner, meaning that if a sub-tree dispatched in a multithreaded manner also contains a control marked for preRender forking, the inner control will not be executed in an additional thread. However, as long as controls marked for multithreaded preRender aren't descendants of one another, they will be performed in tandem with each other and the main tree walk. At the end of the call to walkRecursivePreRender, the ControlTreeWalker pool is used to wait for the spawned WalkerWorkers to complete their processing before continuing on to the next lifecycle stage.
Multithreaded render is useful in cases where a control's long-running processing requires that the control immediately render into the response. The most common case of this is using a RequestDispatcher to include content that either itself is long-running, or is from an external site. In this case, the implementation is actually composed of three components: a ControlRenderQueue, a class called RenderWorker that extends WalkerWorker, and a modified version of ControlTree Walker. walkRecursive called walkRecursiveRender. A ControlRenderQueue is used to collect UIControls marked for forkedRender during the pre-render phase, and to collect the render results of those UIControls after they are dispatched to ExecuteThreads. This collection marking phase works similarly to multithreaded preRender qualification, where only the first control depth-wise is collected into the render queue.
During the render lifecycle walk, the render queue is processed before the main control tree is walked. This processing dispatches all of the queued controls to a RenderWorker class so that rendering can take place for each sub-tree in a separate ExecuteRequest. After the processing has been started, the mainline ControlTreeWalker uses the ControlTreeWalkerPool to wait until all worker processing has been completed. In order to allow control rendering to be performed on multiple threads, and to allow this rendering to occur before the mainline render, each RenderWorker creates a BufferedJspContext which is set on the sub-tree it will render. Each BufferedJspContext creates BufferedRequest and BufferedResponse objects that are wrappers for the original HttpServletRequest and HttpServletResponse objects, respectively.
BufferedRequest delegates to the underlying wrapped request, except for access to request attributes, via overrides of the getAttribute, setAttribute and getAttributeNames methods of ServletRequest. Additionally, BufferedRequest implements a method that can be used to transfer the sequence of setAttribute calls back to the original request after all buffered operations are completed. The BufferedRequest is necessary in the netuix framework because communication between various included portions of a portal, such as between the main portal file and .portlet or .jsp files, is accomplished by setting context instances into request attributes before performing RequestDispatcher includes.
BufferedResponse delegates to the underlying wrapped response, except for operations that affect the response Writer or OutputStream. Calls to getWriter or getOutputStream are instead diverted to instances based on an internal ByteArrayOutputStream that serves to buffer render output from a UIControl. After setting the BufferedJspContext onto a control subtree, the RenderWorker initiates a render walk on the control tree. Each control then uses either the BufferedJspContext and its underlying buffered request and response objects as normal, or simply uses the writer object obtained from the buffered response as normal. The usage of these buffered request and response objects are completely transparent to the rendering controls, and there is no special coding or handling that is required to use the buffered versions. However, the render code should be thread-safe.
Once all RenderWorker processing is complete, the mainline render operation begins. When the ControlTreeWalker worker encounters a control that has been previously rendered by a WalkerWorker, instead of performing the regular render visit on that control, it uses the ControlRenderQueue to obtain the render result for the control, and writes that data into the result.
In one embodiment, look and feel ("L&F") is inherent in an application's GUI. The elements of a GUI that allow a user to functionally interact with it comprise the "feel" of L&F. By way of a non-limiting example, these might be windows, menus, buttons, text fields, etc. The general appearance of these elements comprise the "look" of L&F. By way of a non-limiting example, a look can consist of a button image, the color of a menu, the font in which text is displayed, etc. Thus, a given GUI "feel" may have more than one "look", and vice versa.
In one embodiment, L&F includes three components: a LookAndFeel control, one or more skins, and one or more skeletons. The LookAndFeel control associates a skeleton with a skin (and other configuration attributes). Skins specify superficial information for a GUI element and provide a means for an GUI to embrace different "looks" while retaining the core functionality laid out by the skeleton (which provides the "feel"). A skeleton provides the general appearance and functioning of a GUI element. A skeleton is married to a skin at render time to perfect its "look". In one embodiment, a skeleton includes one or more JSP files. The JSPs that together constitute a given skeleton can be assembled in a directory, the name of which is used to identify the skeleton. References to the skeleton can be made by referencing the containing directory and that directory's path if it differs from a default path (e.g., "/framework/skeletons"). Furthermore, a default skeleton can be provided (e.g., named "default") and located in a default skeleton path. In the absence of skeleton settings to the contrary, the default skeleton in the default location can be assumed by the framework.
In one embodiment, a skeleton can be used to render HTML content. In another embodiment, skeletons can be used to render anything that can be rendered by a JSP. In yet another embodiment, a skeleton can render any of the several forms of XML, either standard or custom (e.g., XHTML, custom XML consumed by Flash MX by Macromedia, etc.). In one embodiment, a skeleton can include a set of JSP files, each of which can be associated with a particular control (sub-classed from PresentationControl) in a control tree.
The PresentationControl superclass provides default rendering using a skeleton in the absence of more explicit rendering. PresentationControl is a superclass for most framework controls, including (but not limited to) the following: Desktop, Shell, Head, Body, Header, Footer, Book, SingleLevelMenu, Page, Layout, Placeholder, Window, Titlebar, and ToggleButton. In one embodiment, for each PresentationControl there is at least one skeleton JSP defined. Situations may arise where a skeleton JSP provided by the chosen skeleton does not meet the needs of a particular instance of a PresentationControl. In this case, the skeleton JSP can be overridden with content from a universal resource identifier ("URI").
In one embodiment, a skeleton JSP's structure is oriented toward control rendering. Like a control, there are both begin and end render states. In the JSP these phases are represented as "beginRender" and "endRender" tags from a JSP render tag library. In general, the contents of these tags are rendered in turn with a control's children rendered in between. However, much finer-grained control can be achieved if desired. Specific children can be retrieved and rendered in explicit locations in order to provide maximum structural layout potential.
In one embodiment, skins provide a way to alter the overall look of GUI without modifying it's fundamental functionality. The definition of a skin can depend on how the skeleton or skeletons it expects to be used with are defined. By way of a non-limiting example, if a skeleton is defined to use a particular cascading style sheet (CSS) class, then the skin needs to define a corresponding rule for that class. Skins can be identified by the directory in which they live. References to the skin can be made by referencing the containing directory and that directory's path if it differs from a default path (e.g., "/framework/skins"). Furthermore, a default skin can be provided named "default" and located in the default skin path. In the absence of skin settings to the contrary, the default skin in the default location is assumed by the rendering system.
A skin can be described by a properties file (e.g., a file named "skin.properties") located in the root level of it's containing directory. The properties file can associate the skin with resources. The property images.path can be used to specify a location where skin-related images can be found. Subdirectories of this directory can be used to store alternate image sets for use by themes. In one embodiment, this property is optional and defaults to the value "images". For example, a properties file might include the following definition:
images.path: images
A link entries section of the properties file can be used to configure link entries, such as CSS references. Such entries are generally HTML-oriented, but could be used by an alternate rendering scheme (e.g. XML) in a way parallel to that described herein. Property entries for this section essentially encapsulate an HTML "link" tag. In one embodiment, this can be accomplished as follows:
An "index" link attribute can be included. This attribute is not rendered in the HTML output, but is instead used to determine the order of the output with respect to link tags representing other property groups. In one embodiment, the index attribute can be any integer value. Rendering of indexed property groups will occur in ascending order, with any remaining, un-indexed groups being rendered last in an arbitrary order relative to one another. This attribute is optional.
For example, these properties:
<link href="{qualified skin path}/css/input.css"
rel="stylesheet" media="screen"/>
<link href="{qualified skin path}/css/document.css"
rel="stylesheet" media="screen"/>
In one embodiment, script entries can be placed in a "script entries" section. This section can be used to configure script entries, such as JavaScript references. Property entries for this section essentially encapsulate an HTML script. By way of a non-limiting example, this can be accomplished as follows:
(5) The union of (1)-(4) yields a complete property name usable in this section; as long as at least one attribute is specified with a value in a given script group
An "index" script attribute can be included. This attribute is not rendered in the HTML output, but is instead used to determine the order of the output with respect to script tags representing other property groups. The index value can be any integer value. Rendering of indexed property groups will occur in ascending order, with any remaining, unindexed groups being rendered last in an arbitrary order relative to one another. This attribute is optional.
For example, these properties:
<script src="{qualified skin path}/js/util.js" type="text/javascript"></script> <script src="{qualified skin path}/js/skin.js" type="text/javascript"></script>
Script hrefs can be defined relative to the "skin.properties" file.
In one embodiment, the properties document.body.onload and document.body.onunload allow a skin to associate a "body" tag's "onload" and "onunload" with event handlers. Doing so will cause the value of either property to be inserted into the beginning of the appropriate event handler's command list before rendering. The end result is the evaluation of said property value after the document has been completely loaded, allowing skin scripts to apply themselves to the document. Typically, the values of these properties are script function calls defined in one of the script declarations from the previous section. For example, this property:
document.body.onload: addSkinEventHandlers( )
<body onload="addSkinEventHandlers( );">
If a skin was written to be used specifically with a particular skeleton implementation, the properties default.skeleton.id and default.skeleton.path can be set to specify that skeleton. In the absence of skeleton or skeletonPath attributes of the L&F control the values of these properties is used instead of the catch-all default skeleton and skeletonPath. The path property can be defined relative to the webapp.
Metadata can be predefined by setting the property enable.meta.info. A common use for this data is as a convenience for testing or debugging. For example, adding information about the look and feel in use can aid in test development in that the tests can identify the document style being handled and can adjust it's testing methodologies or reporting as appropriate. In one embodiment, this data manifests in HTML as a series of <meta/> tags located in the document head. Absence of this property or any value other than "true" will yield a false setting, which will mute the output of such meta info.
The resources provided by the skin define what it is, though it's the skeleton and the skin.properties file that bring form to those resources, making them tangible. A skin can consist of any number of resources, and of any type that the target skeleton(s) can take advantage of. The following is a list of several of the most common types, and some notes about their manifestation as elements of a skin.
In one embodiment, a web application can have an images directory associated with it via the Look and Feel, whether or not the images property was specified in the skin.properties file. Of course, if the skeleton never references any images, then no images are used. The images directory can also be set to be equal to the skin directory itself, which is done by setting the skin.properties property images.path to the empty string.
Another component of modern Web sites is the Cascading Style Sheet. Skins are able to strongly leverage their decoupling from skeletons by putting CSS to work. While not required, CSS can be the meat and potatoes of making a skin work. Of course, they won't work gracefully just because the skin wants them to—the skin's target skeleton(s) will need to provide the appropriate hooks (typically in the form of id and class declarations) for them to be maximally effective.
Note, too, that some skeletons allow control-overridden CSS styles and classes via the control declaration in a web application source file. Either situation can cause rendering anomolies (which is usually the purpose of the overrides) that affect the Look and Feel's appearance. Look for this if incorrect rendering behavior seems to appear in the web application.
Scripts can be a powerful ally for client-side dynamic behaviors. Typically manifesting as JavaScript or another ECMAScript-compliant language, client-side scripting can be bootstrapped from the web application's skin. Great amounts of additional interactivity can be added, with or without the help of the underlying skeleton code. For instance, using the skin.properties property document.body.onload and a script declaration one can initialize an entire document to suit a particular purpose or purposes. Suppose it was desired that all well-defined buttons found in window titlebars had a simple rollover effect achieved by swapping images during mouse overs. The following example code makes that simple, and it can all be specified from the skin itself.
For the example, assume that the standard set of images exist in the skin, along with a new version of each named with the indicator "-active" right before the image file extension, as the next example illustrates:
Themes can be defined and implemented across skeletons and skins to provide variations of either in explicitly defined contexts. Explicit portions of a GUI can take direct control over the L&F of a rendered region and work within or step outside of the L&F framework described herein; this is accomplished by overriding skeleton infrastructure for particular elements (controls). A theme is a construct that allows subgroups of a portal instance to use different virtual look and feels than the main rendering area. Themes can be useful for creating specialized areas of the portal that would otherwise complicate the baseline look and feel development unnecessarily.
For a skin to be useful to a given skeleton (since skins are typically written for particular skeletons) in the context of a particular theme, the skin can support the same set of themes as the skeleton it naturally targets. In one embodiment, given the name of a theme, the LookAndFeel control searches for theme skeleton components in the directory derived by combining the base directory of the skeleton and the name of the theme. Skin theme image resolution works the same way, only using the configured images directory for the skin as the base location.
In the skeleton case, themes manifest as sets of skeleton JSPs in their theme subdirectory as described above. The sets can be complete sets or subsets of the base JSP set for the skeleton. In the case of subsets, no upward resolution is performed if a theme's skeleton JSP is missing—this is an error condition. Any JSP in the theme set is simply a variation on the base skeleton and is used instead of the base skeleton JSP when the theme's scope is in effect.
A Theme control manifests as a wrapper around other controls and entities. By applying a theme in this way, the theme's children are rendered with the skeleton and skins resources defined by the enveloping theme. The following attributes are particularly noteworthy elements of theme control: "name", "usingAltSkeleton", and "usingAltImages". The "name" attribute is already well known—it defines the unique id as well as the skeleton and skin images subdirectories used when resolving a theme context.
The "usingAltSkeleton" attribute is a boolean switch; a value of "false" indicates that the Look and Feel should not try to use skeleton JSPs from a subdirectory of the base skeleton directory—it should instead use the default skeleton JSPs. A value of "false" can be useful when only the skin side of the theme is of interest to the region of code being themed. The default value is "true".
The "usingAltImages" attribute is a boolean switch as well; a value of "false" indicates that image resources should not be pulled from the theme-defined subdirectory of the skin images directory, but should instead be pulled from the normal images area. A value of "false" can be useful when only the skeleton side of the theme is of interest to the region being themed. The default value is again "true".
<netuix:theme name="MyTheme" usingAltSkeleton="false"> <netuix:window ...> ... </netuix:window> </netuix:theme>
In this simple case, the enveloped window control instance would be rendered with the skeleton and skin resources identified by the theme named "MyTheme".
The crux of the concepts, implementations, and controls discussed so far is the LookAndFeel control. The LookAndFeel control has the following attributes in one embodiment:
In one embodiment, a user can customize (or personalize) a web application to suit their needs. A template is a definition of a web application and can reside in a library. Changes made to a template can be propagated to portlet instances, at the discretion of the administrator. Streaming control trees allow for personalized representations of requests. For example, a page can contain only portlets (controls trees) that the user has selected or that entitlement rules have selected for the user. Each user may select different sets of portlets. A streaming control tree factory can map each user into an individual control stream and then construct a control tree from it. The streaming control tree factory hides all the details about how the control tree is generated and how personalization occurs. The control tree representation may be cached and may be regenerated if the stream changes. For example, if a user selects a different set of portlets to be visible.
In one embodiment, a user's attributes (e.g., name, age, position, etc.) and/or group membership can be used to automatically choose a L&F. By way of a non-limiting example, when a user first visits a portal, the user is considered an anonymous visitor and thus will see a default L&F for the portal. Once a user logs into the portal, a L&F can be automatically applied to the portal based on the user's characteristics or other information (e.g., time of day, external data, etc.).
One embodiment may be implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
One embodiment includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the features presented herein. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and user applications.
The foregoing description of the preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations is apparent to the practitioner skilled in the art. Embodiments were chosen and described in order to best describe the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention, the various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents.
|Patente citada
|Fecha de presentación
|Fecha de publicación
|21 May 1993
|15 Mar 1994
|Xerox Corporation
|Display of hierarchical three-dimensional structures with rotating substructures
|3 May 1996
|10 Nov 1998
|Webmate Technologies, Inc.
|Client-server system using embedded hypertext tags for application and database development
|24 Sep 1998
|5 Sep 2000
|Mci Communications Corporation
|Graphical user interface for Web enabled applications
|25 Nov 1998
|24 Abr 2001
|Zerox Corporation
|Interactive interface for specifying searches
|22 Sep 1995
|19 Jun 2001
|Next Software, Inc.
|Method and apparatus for managing internet transactions
|2 Jun 1997
|31 Jul 2001
|Microsoft Corporation
|System and method for facilitating generation and editing of event handlers
|19 May 2000
|4 Dic 2001
|Epicentric, Inc.
|Portal server that provides a customizable user Interface for access to computer networks
|8 Sep 1995
|26 Nov 2002
|Xerox Corporation
|Display system for displaying lists of linked documents
|7 Feb 2001
|17 Ago 2004
|International Business Machines Corporation
|Customer self service iconic interface for portal entry and search specification
|10 May 2002
|11 Abr 2006
|Changing World Limited
|Intelligent internet website with hierarchical menu
|28 Dic 2001
|19 Sep 2006
|Oracle International Corporation
|Customization of tab-order functionality in internet applications
|10 Jul 2001
|3 Oct 2006
|Microsoft Corporation
|Application program interface that enables communication for a network software platform
|10 Jul 2001
|10 Oct 2006
|Microsoft Corporation
|User control objects for providing server-side code generation from a user-defined dynamic web page content file
|31 Ago 2001
|26 Dic 2006
|Gxs, Inc.
|Method, system, and software for generating and displaying custom views for accessing multiple applications
|4 Abr 2002
|10 Abr 2007
|Microsoft Corporation
|System and methods for constructing personalized context-sensitive portal pages or views by analyzing patterns of users' information access activities
|5 Nov 2001
|15 Ago 2002
|Terry Bernard Young
|Electronic markets business interchange system and method
|26 Feb 2001
|29 Ago 2002
|Hough P. J.
|Method for flagging and relating information in a computer system
|12 Jun 2001
|12 Dic 2002
|Rui Zhou
|Collaboration control system and method
|5 Jul 2002
|16 Ene 2003
|Shiigi Clyde K.
|Web site application development method using object model for managing web-based content
|19 Sep 2001
|20 Mar 2003
|International Business Machines Corporation
|Building distributed software services as aggregations of other services
|15 Ago 2002
|26 Jun 2003
|Visa U.S.A.
|Method and system for delivering multiple services electronically to customers via a centralized portal architecture
|24 Oct 2002
|3 Jul 2003
|Griffin Philip B.
|System and method for XML data representation of portlets
|19 Sep 2002
|25 Mar 2004
|Igor Zaika
|System and method for describing and instantiating extensible user interfaces
|15 Oct 2002
|15 Abr 2004
|Tupper Joseph L.
|Optimized parametric modeling system and method
|15 Nov 2002
|20 May 2004
|Humanizing Technologies, Inc.
|Customized life portal
|18 Feb 2003
|1 Jul 2004
|Hyeokman Kim
|Techniques for constructing and browsing a hierarchical video structure
|9 Oct 2003
|8 Jul 2004
|International Business Machines Corporation
|Dynamic portal assembly
|Geary, "Graphic Java Mastering the JFC vol. 2: Swing", 1999, Sun Microsystems Press, 3rd Edition, 12 pages.
|Geary, "Graphic JAVA Mastering the JFC", Sun Microsystems, 1999, 10 pages.
|Geary, "Graphic Java, Mastering the JFC", 1999, 24 pages, vol. II, Swing, Sun Microsystems Press.
|Graham, "The HTML Sourcebook, A Complete Guide to HTML 3.0", 1996, 4 pages, 2nd Edition, John Wiley and Sons.
|Hougland, et al., "Core JSP", 2001, 4 pages, Prentice Hall PTR, Upper Saddle River, NJ.
|Hunter, "Java Servlet Programming", 2001, pp. 261-267, O'Reilly & Co.
|Hunter, Java(TM) Servlet Programming by Jason Hunter, Copyright (c) 2001, 1998 O'Reilly & Associates, Inc. pp. 485-486.
|Hunter, Java™ Servlet Programming by Jason Hunter, Copyright (c) 2001, 1998 O'Reilly & Associates, Inc. pp. 485-486.
|Java(TM) Servlet Programming by Jason Hunter, 2nd Edition, Copyright (c) 2001, 1998 O'Reilly & Associates, Inc., pp. 1-24.
|Java™ Servlet Programming by Jason Hunter, 2nd Edition, Copyright (c) 2001, 1998 O'Reilly & Associates, Inc., pp. 1-24.
|Knudsen, et al., "Learning Java", May 2000, 48 pages, O'Reilly & Associates, Inc.
|Meckler, "Java and Inter-Applet Communication", Oct. 1, 1997, 11 pages, Dr. Dobb's Journal. retrieved from http://www.ddj.com/java/184410295.
|Monson-Haefel, Enterprise JavaBeans, 1999, 4 pages, 2nd Edition, O'Reilly & Associates.
|Moss, "Java Servlets", 1999,5 pages, McGraw-Hill, New York.
|Moss, "JavaServlets", 1999, 26 pages, McGraw-Hill.
|Schildt, "Java 2: The Complete Reference", 2002, 6 pages, 5th Edition, McGraw-Hill, New York.
|Schildt, The Complete Reference, 2002, pp. 654-656, Fifth Ed., McGraw Hill/Osborne.
|Patente citante
|Fecha de presentación
|Fecha de publicación
|3 Ago 2007
|6 Sep 2011
|International Business Machines Corporation
|Rapidly assembling and deploying selected software solutions
|30 Dic 2004
|22 Nov 2011
|Massachusetts Institute Of Technology
|Techniques for relating arbitrary metadata to media files
|26 Sep 2011
|3 Jul 2012
|Limelight Networks, Inc.
|Methods and systems for abridging video files
|26 Sep 2011
|12 Mar 2013
|Limelight Networks, Inc.
|Methods and systems for generating automated tags for video files
|21 Sep 2007
|24 Feb 2015
|Limelight Networks, Inc.
|Visual interface for identifying positions of interest within a sequentially ordered information encoding
|1 Jul 2009
|7 Abr 2015
|Sprint Communications Company L.P.
|Graphical user interface dynamic menu slot
|15 Jun 2012
|21 Abr 2015
|Limelight Networks, Inc.
|Method and subsystem for searching media content within a content-search service system
|9 Abr 2009
|2 May 2017
|International Business Machines Corporation
|Web-browser based state repository
|31 Ago 2015
|17 Oct 2017
|Home Box Office, Inc.
|Factory identification system
|30 Dic 2004
|6 Jul 2006
|Massachusetts Institute Of Technology
|Techniques for relating arbitrary metadata to media files
|29 Jun 2007
|1 Ene 2009
|Merav Simhi
|Visual design tools for portal content creation
|3 Ago 2007
|5 Feb 2009
|Jones Andrew R
|Rapidly Assembling and Deploying Selected Software Solutions
|9 Abr 2009
|14 Oct 2010
|International Business Machines Corporation
|Web-Browser Based State Repository
|5 Mar 2014
|6 Nov 2014
|Ipath Technologies Private Limited
|Techniques for enterprise resource mobilization
|31 Ago 2015
|10 Mar 2016
|Home Box Office, Inc.
|Factory identification system
|12 Sep 2011
|18 Sep 2012
|Microsoft Corporation
|Display screen with graphical user interface
|14 Mar 2014
|24 May 2016
|Amazon Technologies, Inc.
|Display screen having a graphical user interface for packing items
|27 Feb 2014
|28 Jun 2016
|Amazon Technologies, Inc.
|Display screen having a graphical user interface
|27 Feb 2014
|5 Jul 2016
|Amazon Technologies, Inc.
|Display screen having a graphical user interface
|Clasificación de EE.UU.
|715/762, 715/826, 715/763, 715/855, 715/825, 715/854
|Clasificación internacional
|Clasificación cooperativa
|Clasificación europea
|30 Ago 2004
Owner name: BEA SYSTEMS, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OLANDER, DARYL B.;FEIT, RICHARD;O'NEIL, EDWARD K.;AND OTHERS;REEL/FRAME:015097/0712;SIGNING DATES FROM 20040602 TO 20040827
|15 Oct 2010
Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BEA SYSTEMS, INC.;REEL/FRAME:025192/0244
Effective date: 20101008
|23 Nov 2010
|Certificate of correction
|30 Nov 2010
|Certificate of correction
|14 Dic 2010
|Certificate of correction
|13 Mar 2013
|Fee payment
Year of fee payment: 4
|6 Jul 2017
|Fee payment
Year of fee payment: 8

subset: commoncrawl


text:
Biography: Cecil Buller
Cecil Buller
Born in Montreal, Quebec, 15 September 1886
Died in Montreal, Quebec, 29 September 1973
Cecil Buller, Portrait of the Artist, 1949
Biographical forms
"A good [engraving] should strike the viewer from a distance? ? Today?s Art - 1963
Cecil Buller, an award-winning printmaker, illustrator, designer, watercolourist and painter played an active role in the wood engraving revival of the early 20th century. Her engravings superbly exploited the medium?s expressive possibilities through the use of a decorative and lyrical vocabulary.
She first studied at the Art Association of Montreal (now the Montreal Museum of Fine Arts) under the guidance of William Brymner. After a stint at the progressive Art Students League in New York in 1910, she travelled to Paris to study privately with Maurice Denis, the founding member of the Nabis. She decided to concentrate on graphic arts and moved to London in 1916 to study with famed British printmaker Noel Rooke, at the Central School of Art and Design. There she met American artist and future husband John Murphy, with whom she moved to New York.
In New York, she earned a considerable reputation for her wood engravings. She produced her masterpiece Song of Solomon, a suite of eleven wood engravings in 1929. She continued working in a variety of techniques, such as lithography and she started using the figure in a more subjective way to express her ideas about the human condition. In 1961 she returned to Montreal where she lived until her death at 87. She was awarded the Pennel Prize, Library of Congress, D.C. (1945), the Audubon Society Award (1947 and 1953) and the National Academy of Design Graphic Art Award (1949).


text:
The kickass survival site for anyone who's ever been lied to, cheated on and left for dead.
Separating or Divorcing, Part 3 (Part 2 is FULL)
- Home
- Join the Club...and Share Your Story
- Books for the Betrayed
- Share Your Story: Finding Out, Part 4 (3 is full!!...
- Share Your Story: Multiple Affairs PART 2
- Stupid S#*t Cheaters Say
- Just found out? Share your story...
- Finding Out, Part 5 (Please post here. Part 4 is f...
- Feeling Stuck? Part 21
- Separating or Divorcing? Page 5
- Sex and intimacy after betrayal
- Share Your Story: Finding Out, Part 5 (4 is full!!...
- Separating or Divorcing, Page 6
- Feeling Stuck, Page 22
Wednesday, February 15, 2012
Mother Shit
In any case, we ended up talking about my husband's family. These people are crazy. The kind of crazy that looks, at first glance, like normal. As in, "I can't believe how nice your family is. They're so...sane." That's what I said to my husband the first time I had dinner with his family. Compared to my family of alcoholics and artists (often the same thing), his family seemed like the Brady Bunch. The kind of people who could wrap up any dilemma in a half-hour, including commercials. Admittedly I wasn't exactly great at recognizing "sane" having never seen it up close in my entire life. I was, however, an optimist. And completely unversed in dysfunction that wasn't readily apparent. Alcoholics at least offer up the advantage that they're clearly crazy. Drinking vodka at 8 a.m. out of a coffee mug is hard to ignore.
But then I got to know my husband's family. And it slowly (I mean s-l-o-w-l-y...over years and years) became clear that these people were dangerously crazy. For years, I thought it was me. Growing up with alcoholics made me something of an expert in accepting blame for pretty much anything that has been/is/might go wrong. So I took the blame...something my husband was happy to facilitate. I was too sensitive. I tried too hard. Expected too much. Didn't have a sense of humor. Couldn't just accept people. I worried too much. And on and on.
So I spent a decade trying to dance on broken glass while juggling plates over my head and trying not to get hurt. And I failed miserably every single time.
And then came the day when I learned of my husband's affair. I curled into a ball and shut out as much of the world as I could. I had noticed how much his affair partner (the one I knew about at that time) was like his mother: cold, critical, cruel. Fat. (Immature of me, I know. But she was!) And yet, like with his mother, he couldn't seem to extricate himself from her though he could barely stand to be in the same room as her.
All Freudian analysis aside, it was a bizarre situation that ultimately gave me the freedom to distance myself from my husband's mother. I allowed myself to lick my wounds, free from her criticism and cruelty. (I had said to my husband that, given my fragile emotional state, he took his chances putting the two of us in the same room. His desire to keep her ignorant of his adultery overshadowed his desire to be the dutiful son with the dutiful wife.) And though much of my life sucked at that time, the fact that she was only marginally in it was a bright spot.
Fast forward to today:
My husband, having since confessed a sex addiction that he and a band of supporting psychologists/psychiatrists agree is rooted in his mother's cruelty, criticism and ultimately non-existent nurturing, wants me to spend "Family Day" (a fabricated Canadian holiday that most families seem to spend trying to find childcare for their children) with his mother.
Wha??? I want to scream. This isn't, of course, the first time he's asked me to bury the hatchet...and not in her back, though that's an invitation I might accept.
My incredulity comes from the fact that, in my estimation, he allowed her to bully and badger me for years, has asked me to accept her poor mothering as the catalyst for an addiction that brought me to my knees, and now just wants us all to get along. And by "get along" he means allowing her to behave like a petulant toddler while the rest of us sigh and chalk it up to, "well...that's just mom."
As I'm forever writing on this blog, I know I'm in charge of my own emotions...and expecting him to change simply because I don't like this part of him is an exercise in futility. The relationship between a child and his/her mother is a complex one, frequently more complex the deeper the dysfunction.
Unfortunately though, this feels like yet another abandonment by him in a relationship marked by abandonment. Yeah, yeah...the past is the past. I know. But when the past keeps on sneaking up on me and biting me in the ass, then it quickly becomes the present. And I would prefer a present in which my husband stops sacrificing me on the alter of his mother.
I've been sacrificed quite enough, thank-you.
7 comments:
Great stuff Elle. Thanks for the follow. There is this great blog marriagesrestored.com to add to your links we love. :)ReplyDelete
And here is a toast to kicking infidelity's ass. You go.
- AnonymousJuly 30, 2012 at 7:43 PM
are you and I long lost sisters with twin husbands?? seriously....ReplyDeleteReplies
I think there's a lot of us sisters out there! :)Delete
- AnonymousJuly 4, 2014 at 4:08 AM
Maybe the opposite type of mother can be as bad. I had the MIL who thought the sun shone out of her son, not her daughter as women didn't count. The kind who totally obsesses over every detail of her son's life and who would have laid down her life for the male members of her family. During the start of my husband's initial affair with his ex girlfriend I was working very long hours, studying for an advanced degree and looking after our daughter while he absorbed himself in his sports and hobbies. His mother had to be at our house every weekend without fail and I had to be the dutiful daughter in law, any attempt to discuss this met with a brick wall. She has been gone for many years now but I still feel resentful and consider her to be part of our growing apart. My mother and family background was complicated and haphazard but at least I was free from pressure or emotional blackmail.ReplyDeleteReplies
Absolutely. A lot of posters on this site note that their MIL blame them for pushing their beloved sons into affairs. Incredible, huh? Any dysfunctional parent can wreak all sorts of havoc.
I hope you've taken this opportunity though to recognize how you've bought into their family dysfunction by over-functioning (advanced degree while raising kids and working??) and allowing him to under-function. Time for him to grow up and for you to relinquish some control and learn self-care. It's hard (really hard. I speak from experience) but I promise you much of the resentment will dissipate once you begin putting your own needs at the top of the list. Self-care isn't about being selfish -- it's about keeping yourself safe and not agreeing to things that make you feel resentful. Simple, once you get the hang of it. Not to mention, you're modelling really important skills for your own daughter.
- AnonymousMay 11, 2015 at 9:20 AM
This is why my in-laws will not be told. MIL would probably find a way to blame me for my husband's porn addiction and real-world cheating.ReplyDelete
- AnonymousDecember 30, 2016 at 6:33 PM
That's funny, I've never been really close to my in-laws until we moved across country to be near them after my h's affair with a woodchuck. My in-laws were on my side and told my h to find a way to fix what he broke. I guess I'm lucky where that is concerned.ReplyDelete


text:
"It is a custom.
More honored in the breach than the observance." (William Shakespeare)
"Like as the waves make towards the pebbl'd shore, so do our minutes, hasten to their end." (William Shakespeare)
"O beware, my lord, jealousy is the green eye'd monster that doth mock the meat it feeds on." (William Shakespeare)
"O God, I could be bounded in a nutshell and count myself a king of infinite space, were it not that I have bad dreams." (William Shakespeare, Hamlet, 2.2.258-60)
"O' What may man within him hide, though angel on the outward side!" (William Shakespeare)
"Readiness is all." (William Shakespeare)
"Rough winds do shake the darling buds of May." (William Shakespeare)
"The course of true love never did run smooth." (William Shakespeare, A Midsummer Night's Dream, I:1)
"The evil that men do lives after them;
The good is oft interred with their bones." (William Shakespeare, Julius Cćsar. Act iii. Sc. 2.)
"The first thing we do let's kill all the lawyers." (William Shakespeare, II Henry VI, IV:2)


text:
Rapid Expansion of EV Charging Stations Planned
The issue of electric vehicle range anxiety got a thorough airing last week, in the now notorious Tesla vs The New York Times battle. It started when Times reporter John Broder wrote a story about his recent Tesla Model S test drive. While acknowledging that the car itself is a thing of beauty (Motor Trend's Car of the Year, to be precise) Broder detailed a litany of complaints about the driving experience on a 400-mile trip from Washington D.C. to Boston, primarily focusing on battery life and range. The whole thing ended ingloriously, short of the destination point with a spent battery and a tow truck involved.
Of course, taking a 400 mile jaunt (actually more, considering that Broder detoured through New York City) along some of the most heavily traveled arteries in the U.S. during the dead of winter is a dicey proposition under any circumstances, but if Broder set out to demonstrate that electric vehicles are not ready for prime time, he ended up proving something else entirely.
Taking a look at the big picture, clearly the electric vehicle charging infrastructure has not yet penetrated the U.S. market to the extent that gasoline stations have. If you plan on going on a long trip in an EV today, you need to plan it around the availability of charging stations.
However, some parts of the U.S. already do have ample access to charging stations, due to the availability of home and workplace charging as well as public charging stations.
EV charging stations image courtesy Boston University.
Read more at ENN Affiliate, TriplePundit.


text:
One of the most star-studded events last week was the Alexander McQueen: Savage Beauty Costume Institute Gala at The Metropolitan Museum of Art in New York City. All of Hollywood's elite were in attendance and showing off their costumes gowns. The night was hosted by the one and only Oprah Winfrey along with Vogue editor-in-chief Anna Wintour.
The red carpet was filled with A-listers looking magnificent in their designer gowns, often accompanied with the designer themselves. After looking at most of the night's looks it makes me wonder if the stars wearing them actually love what they are wearing. For sure, they are uncomfortable such as Beyonce's skin-tight gown that didn't leave her enough breathing room to walk up the stairs – she had to be carried by 2 men!
There were a lot of hits and misses of the night that I want to share with you. Tell me what you think.
The Hits:
Twilight star Ashley Greene who is not normally someone I would pick out from the red carpet but she looked so elegant in Donna Karen. Plus, her cuff bracelet is gorgeous!
Diana Kruger was simple and sophisticated in Jason Wu – probably my favorite look of something I would actually wear.
Madonna who is often seen in not-appropriate-for-her-age black attire opted for a blue silk Stella McCartney dress that hugged her body in a classy way. I was quite impressed with her mature look and love her floral jewelry pieces.
The Misses:
These particular women went wrong in white.
Beautiful Miranda Karr recenlty married cutie Orlando Bloom but at the gala she looked like she was wearing Tinkerbell's wedding dress.
One of these things just doesn't belong here…Serene Williams does not have any fashion sense with this ensemble. It seems she was channeling the Royal Wedding with her choice of headpiece and the dress is just a mess.
Naomi Campbell should know better being a supermodel to show up wearing something like this.
What did you think of the red carpet looks at the MET Gala?
Photos by PR Photos