Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Events
Videos
Audiobooks
Packt Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds

How-To Tutorials

7019 Articles
article-image-objects-python
Packt
27 Jul 2010
15 min read
Save for later

Objects in Python

Packt
27 Jul 2010
15 min read
(For more resources on Python 3, see here.) Creating Python classes We don't have to write much Python code to realize that Python is a very "clean" language. When we want to do something, we just do it, without having to go through a lot of setup. The ubiquitous, "hello world" in Python, as you've likely seen, is only one line. Similarly, the simplest class in Python 3 looks like this: class MyFirstClass: pass There's our first object-oriented program! The class definition starts with the class keyword. This is followed by a name (of our choice) identifying the class, and is terminated with a colon. The class name must follow standard Python variable naming rules (must start with a letter or underscore, can only be comprised of letters, underscores, or numbers). In addition, the Python style guide (search the web for "PEP 8"), recommends that classes should be named using CamelCase notation (start with a capital letter, any subsequent words should also start with a capital).   The class definition line is followed by the class contents, indented. As with other Python constructs, indentation is used to delimit the classes, rather than braces or brackets as many other languages use. Use four spaces for indentation unless you have a compelling reason not to (such as fitting in with somebody else's code that uses tabs for indents). Any decent programming editor can be configured to insert four spaces whenever the Tab key is pressed. Since our first class doesn't actually do anything, we simply use the pass keyword on the second line to indicate that no further action needs to be taken. We might think there isn't much we can do with this most basic class, but it does allow us to instantiate objects of that class. We can load the class into the Python 3 interpreter so we can play with it interactively. To do this, save the class definition mentioned earlier into a file named first_class.py and then run the command python -i first_class.py. The -i argument tells Python to "run the code and then drop to the interactive interpreter". The following interpreter session demonstrates basic interaction with this class: >>> a = MyFirstClass() >>> b = MyFirstClass() >>> print(a) <__main__.MyFirstClass object at 0xb7b7faec> >>> print(b) <__main__.MyFirstClass object at 0xb7b7fbac> >>> This code instantiates two objects from the new class, named a and b. Creating an instance of a class is a simple matter of typing the class name followed by a pair of parentheses. It looks much like a normal function call, but Python knows we're "calling" a class and not a function, so it understands that its job is to create a new object. When printed, the two objects tell us what class they are and what memory address they live at. Memory addresses aren't used much in Python code, but here,it demonstrates that there are two distinctly different objects involved. Adding attributes Now, we have a basic class, but it's fairly useless. It doesn't contain any data, and it doesn't do anything. What do we have to do to assign an attribute to a given object? It turns out that we don't have to do anything special in the class definition. We can set arbitrary attributes on an instantiated object using the dot notation: class Point: pass p1 = Point() p2 = Point() p1.x = 5 p1.y = 4 p2.x = 3 p2.y = 6 print(p1.x, p1.y) print(p2.x, p2.y) If we run this code, the two print statements at the end tell us the new attribute values on the two objects: 5 4 3 6 This code creates an empty Point class with no data or behaviors. Then it creates two instances of that class and assigns each of those instances x and y coordinates to identify a point in two dimensions. All we need to do to assign a value to an attribute on an object is use the syntax <object>.<attribute>=<value>. This is sometimes referred to as dot notation. The value can be anything: a Python primitive, a built-in data type, another object. It can even be a function or another class! Making it do something Now, having objects with attributes is great, but object-oriented programming is really about the interaction between objects. We're interested in invoking actions that cause things to happen to those attributes. It is time to add behaviors to our classes. Let's model a couple of actions on our Point class. We can start with a method called reset that moves the point to the origin (the origin is the point where x and y are both zero). This is a good introductory action because it doesn't require any parameters: class Point: def reset(self): self.x = 0 self.y = 0 p = Point() p.reset() print(p.x, p.y) That print statement shows us the two zeros on the attributes: 0 0 A method in Python is identical to defining a function. It starts with the keyword def followed by a space and the name of the method. This is followed by a set of parentheses containing the parameter list (we'll discuss the self parameter in just a moment), and terminated with a colon. The next line is indented to contain the statements inside the method. These statements can be arbitrary Python code operating on the object itself and any parameters passed in as the method sees fit. The one difference between methods and normal functions is that all methods have one required argument. This argument is conventionally named self; I've never seen a programmer use any other name for this variable (convention is a very powerful thing). There's nothing stopping you, however, from calling it this or even Martha. The self argument to a method is simply a reference to the object that the method is being invoked on. We can access attributes and methods of that object as if it were any other object. This is exactly what we do inside the reset method when we set the x and y attributes of the self object. Notice that when we call the p.reset() method, we do not have to pass the self argument into it. Python automatically takes care of this for us. It knows we're calling a method on the p object, so it automatically passes that object to the method. However, the method really is just a function that happens to be on a class. Instead of calling the method on the object, we could invoke the function on the class, explicitly passing our object as the self argument: p = Point() Point.reset(p) print(p.x, p.y) The output is the same as the previous example because, internally, the exact same process has occurred. What happens if we forget to include the self argument in our class definition? Python will bail with an error message: >>> class Point: ... def reset(): ... pass ... >>> p = Point() >>> p.reset() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: reset() takes no arguments (1 given) The error message is not as clear as it could be ("You silly fool, you forgot the self argument" would be more informative). Just remember that when you see an error message that indicates missing arguments, the first thing to check is whether you forgot self in the method definition. So how do we pass multiple arguments to a method? Let's add a new method that allows us to move a point to an arbitrary position, not just the origin. We can also include one that accepts another Point object as input and returns the distance between them: import math class Point: def move(self, x, y): self.x = x self.y = y def reset(self): self.move(0, 0) def calculate_distance(self, other_point): return math.sqrt((self.x - other_point.x)**2 +(self.y - other_point.y) **2) # how to use it: point1 = Point() point2 = Point() point1.reset() point2.move(5,0) print(point2.calculate_distance(point1)) assert (point2.calculate_distance(point1) == point1.calculate_distance(point2)) point1.move(3,4) print(point1.calculate_distance(point2)) print(point1.calculate_distance(point1)) The print statements at the end give us the following output: 5.0 4.472135955 0.0 A lot has happened here. The class now has three methods. The move method accepts two arguments, x and y, and sets the values on the self object, much like the old reset method from the previous example. The old reset method now calls move, since a reset is just a move to a specific known location. The calculate_distance method uses the not-too-complex Pythagorean Theorem to calculate the distance between two points. I hope you understand the math (** means squared, and math.sqrt calculates a square root), but it's not a requirement for our current focus: learning how to write methods. The example code at the end shows how to call a method with arguments; simply include the arguments inside the parentheses, and use the same dot notation to access the method. I just picked some random positions to test the methods. The test code calls each method and prints the results on the console. The assert function is a simple test tool; the program will bail if the statement after assert is False (or zero, empty, or None). In this case, we use it to ensure that the distance is the same regardless of which point called the other point's calculate_distance method. Initializing the object If we don't explicitly set the x and y positions on our Point object, either using move or by accessing them directly, we have a broken point with no real position. What will happen when we try to access it? Well, let's just try it and see. "Try it and see" is an extremely useful tool for Python study. Open up your interactive interpreter and type away. The following interactive session shows what happens if we try to access a missing attribute. If you saved the previous example as a file or are using the examples distributed in this article, you can load it into the Python interpreter with the command python -i filename.py. >>> point = Point() >>> point.x = 5 >>> print(point.x) 5 >>> print(point.y) Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'Point' object has no attribute 'y' Well, at least it threw a useful exception. You've probably seen them before (especially the ubiquitous SyntaxError, which means you typed something incorrectly!). At this point, simply be aware that it means something went wrong. The output is useful for debugging. In the interactive interpreter it tells us the error occurred at line 1, which is only partially true (in an interactive session, only one line is executed at a time). If we were running a script in a file, it would tell us the exact line number, making it easy to find the offending code. In addition, it tells us the error is an AttributeError, and gives a helpful message telling us what that error means. We can catch and recover from this error, but in this case, it feels like we should have specified some sort of default value. Perhaps every new object should be reset() by default or maybe it would be nice if we could force the user to tell us what those positions should be when they create the object. Most object-oriented programming languages have the concept of a constructor, a special method that creates and initializes the object when it is created. Python is a little different; it has a constructor and an initializer. Normally, the constructor function is rarely ever used unless you're doing something exotic. So we'll start our discussion with the initialization method. The Python initialization method is the same as any other method, except it has a special name: __init__. The leading and trailing double underscores mean, "this is a special method that the Python interpreter will treat as a special case". Never name a function of your own with leading and trailing double underscores. It may mean nothing to Python, but there's always the possibility that the designers of Python will add a function that has a special purpose with that name in the future, and when they do, your code will break. Let's start with an initialization function on our Point class that requires the user to supply x and y coordinates when the Point object is instantiated: class Point: def __init__(self, x, y): self.move(x, y) def move(self, x, y): self.x = x self.y = y def reset(self): self.move(0, 0) # Constructing a Point point = Point(3, 5) print(point.x, point.y) Now, our point can never go without a y coordinate! If we try to construct a point without including the proper initialization parameters, it will fail with a not enough arguments error similar to the one we received earlier when we forgot the self argument. What if we don't want to make those two arguments required? Well then we can use the same syntax Python functions use to provide default arguments. The keyword argument syntax appends an equals sign after each variable name. If the calling object does not provide that argument, then the default argument is used instead; the variables will still be available to the function, but they will have the values specified in the argument list. Here's an example: class Point: def __init__(self, x=0, y=0): self.move(x, y) Most of the time, we put our initialization statements in an __init__ function. But as mentioned earlier, Python has a constructor in addition to its initialization function. You may never need to use the other Python constructor, but it helps to know it exists, so we'll cover it briefly. The constructor function is called __new__ as opposed to __init__, and accepts exactly one argument, the class that is being constructed (it is called before the object is constructed, so there is no self argument). It also has to return the newly created object. This has interesting possibilities when it comes to the complicated art of meta-programming, but is not very useful in day-to-day programming. In practice, you will rarely, if ever, need to use __new__, and __init__ will be sufficient. Explaining yourself Python is an extremely easy-to-read programming language; some might say it is self-documenting. However, when doing object-oriented programming, it is important to write API documentation that clearly summarizes what each object and method does. Keeping documentation up-to-date is difficult; the best way to do it is to write it right into our code. Python supports this through the use of docstrings. Each class, function, or method header can have a standard Python string as the first line following the definition (the line that ends in a colon). This line should be indented the same as the following code. Docstrings are simply Python strings enclosed with apostrophe (') or quote (") characters. Often, docstrings are quite long and span multiple lines (the style guide suggests that line-length should not exceed 80 characters), which can be formatted as multi-line strings, enclosed in matching triple apostrophe (''') or triple quote (""") characters. A docstring should clearly and concisely summarize the purpose of the class or method it is describing. It should explain any parameters whose usage is not immediately obvious, and is also a good place to include short examples of how to use the API. Any caveats or problems an unsuspecting user of the API should be aware of should also be noted. To illustrate the use of docstrings, we will end this part with our completely documented Point class: import math class Point: 'Represents a point in two-dimensional geometric coordinates' def __init__(self, x=0, y=0): '''Initialize the position of a new point. The x and y coordinates can be specified. If they are not, the point defaults to the origin.''' self.move(x, y) def move(self, x, y): "Move the point to a new location in two-dimensional space." self.x = x self.y = y def reset(self): 'Reset the point back to the geometric origin: 0, 0' self.move(0, 0) def calculate_distance(self, other_point): """Calculate the distance from this point to a second point passed as a parameter. This function uses the Pythagorean Theorem to calculate the distance between the two points. The distance is returned as a float.""" return math.sqrt( (self.x - other_point.x)**2 + (self.y – other_point.y)**2) Try typing or loading (remember, it's python -i filename.py) this file into the interactive interpreter. Then enter help(Point)<enter> at the Python prompt. You should see nicely formatted documentation for the class, as shown in the following screenshot:
Read more
  • 0
  • 0
  • 8592

article-image-building-our-own-plone-3-theme-add-product
Packt
27 Jul 2010
6 min read
Save for later

Building our own Plone 3 Theme Add-on Product

Packt
27 Jul 2010
6 min read
(For more resources on Plone, see here.) We can build our own theme add-on product from scratch. It can be done easily with PasteScript. Just type this on our command line from the root of our buildout: $ cd src$ paster create -t plone3_theme plonetheme.myintranet Answer all the questions with the default option except for: Skin Name: A human facing name for the theme, added to portal_skins, for example, MyIntranetTheme. Skin Base: Name of the theme from which this is copied. By default, it is Plone Default. Answer the default option here. Empty Styles?: If true, it will override default public stylesheets with empty ones. Answer False. Include documentation?: If true, the generated theme will include auto- explanatory documentation, desirable for beginners. The resultant theme add-on product will be generated in the src buildout folder. This add-on is completely usable right now, but it's innocuous. Once installed, it will replace the original Plone default theme with the one in this package. Installing the product Just proceed as any other add-on product. However, since we are developing the product, we should specify it in our buildout by filling the develop directive in the buildout section and the eggs directive in the instance section in our buildout.cfg file: [buildout]...develop = src/plonetheme.myintranet...[instance]...eggs = plonetheme.myintranet Go to the package folder, src/plonetheme.myintranet/plonetheme/myintranet, and edit the configure.zcml file. As we don't want to define an i18n folder, delete the following line if it exists: <i18n:registerTranslations directory="locales" /> And then, rerun buildout.cfg: $ ./bin/buildout$ ./bin/instance fg Now, go to the Add-on Products control panel configlet and install it. If we browse our site, we will notice that nothing has changed, because we've chosen to inherit the default theme in our new one. But, now the theme defined in our theme add-on product is in use in our site. Check it out in portal_skins: Notice three things in the previous screenshot: the Default skin is our recently created skin and three additional Plone skin layers have been added to the top of the layer's precedence order list. These three layers will contain the resources we may need for our new theme. These layers represent three folders inside our package structure; to be more precise, those inside skins folder: Name of the layer/folder Description plonetheme_myintranet_custom_images It will contain our theme images. plonetheme_myintranet_custom_templates It will contain our theme custom templates. plonetheme_myintranet_styles It will contain our theme styles. In fact, this layer organization is merely for convenience, as all the layers can contain any type of resources. Customizing Plone skin layer resources As our theme product is positioning the new layers on the top of the precedence order, the elements we place in these folders will override those in layers with less precedence. Just place our custom resource in any of the layers defined by our product and name it as the original one. Our custom resource will override the default one. We can also place other resources we may use, such as our custom templates, images, and styles as well. Enabling CSS debug mode By default, the changes made to our product will not be available until we restart our instance. For the changes to take effect immediately, we should enable CSS debug mode in CSS resource registry. We will find this setting at the top of the portal_css ZMI view. In debug/development mode, stylesheets are not merged to composites, and caching and compression of CSS is disabled. The registry also sends HTTP headers to prevent browsers from caching the stylesheets. It's recommended to enable this mode during CSS-related development. Remember to turn it off again when we finish CSS modifications, as debug mode affects site performance. Customizing the site logo Plone renders the site logo combining two kinds of resources—the viewlet plone. logo provides the HTML structure needed and a Plone skin layer image. Let's say we want to change the site logo and add an additional logo of our company containing a link to the corporate web besides it. We need to customize the original logo with the logo of our intranet and add the required HTML structure to add the new company logo besides the original one. We will need to customize the original logo and the plone.logo viewlet. Later, we will need to add our company logo as a new Plone skin layer image. Customizing the logo image and adding a new one We should override the original logo image with our customized one. In order to accomplish this, we should rename the image we've chosen to use as our site logo with the same name as the original one. The original logo image is called logo.jpg and it is located in the plone_images skin layer. We override it by simply placing our customized image inside skins/plonetheme_myintranet_custom_images and naming it exactly the same as the original one. Place the image for the second logo here too, and name it as company-logo.png. Customizing the plone.logo viewlet Customizing a viewlet is a little trickier than overriding skin layer resources. We will need to tell Zope that we want to override the original viewlet declaration by creating an overrides.zcml file in the plonetheme/myintranet folder of our custom add-on product, and add the attribute that tells Zope where to find the new template associated to this viewlet: <configure i18n_domain="plonetheme.myintranet"> <!-- The new logo viewlet declaration --> <browser:viewlet name="plone.logo" manager="plone.app.layout.viewlets.interfaces.IPortalHeader" class="plone.app.layout.viewlets.common.LogoViewlet" template="browser/newlogo.pt" permission="zope2.View" /></configure> Then place this Zope page template called newlogo.pt in the browser folder of our add-on product: <a id="portal-logo-company" tal_attributes="href string:http://www.mycompany.com/"> <img src="company-logo.png" alt="Company.com logo" title="Company.com logo"/></a><a metal:define-macro="portal_logo" id="portal-logo" accesskey="1" tal_attributes="href view/navigation_root_url" i18n_domain="plone"> <img src="logo.jpg" alt="" tal_replace="structure view/logo_tag" /></a> We leave the original logo template at the end of the file and add a new link tag with the structure for the new logo and the reference to the new Plone skin layer image (company-logo.png). Restart our instance to see the changes applied. This is needed because we have overridden a viewlet defining an additional ZCML file.
Read more
  • 0
  • 0
  • 1923

article-image-application-session-and-request-scope-coldfusion-9
Packt
27 Jul 2010
8 min read
Save for later

Application, Session, and Request Scope in ColdFusion 9

Packt
27 Jul 2010
8 min read
(For more resources on ColdFusion, see here.) The start methods We will have a look at the start methods and make some observations now. Each method has its own set of arguments. All Application.cfc methods return a Boolean value of true or false to declare if they completed correctly or not. Any code you place inside a method will execute when the start event occurs. These are the events that match with the name of the method. We will also include some basic code that will help you build an application core that is good for reuse and discuss what those features provide. Application start method—onApplicationStart() The following is the code structure of the application start method. You could actually place these methods in any order in the CFC, as the order does not matter. Code that uses CFCs only require the methods to exist. If they exist, then it will call them. We place them in our code so that it helps us to read and understand the structure from a human perspective. <cffunction name="onApplicationStart" output="false"> <cfscript> // create default stat structure and pre-request values application._stat = structNew(); application._stat.started = now(); application._stat.thisHit = now(); application._stat.hits = 0; application._stat.sessions = 0; </cfscript></cffunction> There are no arguments for the onApplicationStart() method. We have included some extra code to show you an example of what can be done in this function. Please note that if we change the code in this method, it will only run at the very first time when an application running in ColdFusion is hit. To hit it again, we need to either change the application name or restart the ColdFusion server. The Application variables section that was previously explained shows how to change the application's name. From the start methods, we can see that we can access the variable scopes that allow persistence of key information. To understand the power of this object, we will be creating some statistics that can be used in most situations. We could use them for debugging, logging, or in any other appropriate use case. Again, we have to be aware that this only gets hit the first time a request is made to a ColdFusion server for that application. We will be updating many of our statistics in the request methods. We will also be updating one of our variables in the session end method. Session start method—onSessionStart() The session start method only gets called when a request is made for a new session. It is good that ColdFusion can keep track of these things. The following is example code that allows us to keep a record of the session-based statistics that is similar to the application-based statistics: <cffunction name="onSessionStart" output="false"> <cfscript> // create default session stat structure and pre-request values session._stat.started = now(); session._stat.thisHit = now(); session._stat.hits = 0; // at start of each session update count for application stat application._stat.sessions += 1; </cfscript></cffunction> You might have noticed that in the previous code we used +=. In ColdFusion prior to version 8, you had to type that particular line in a different way. The following two examples are the same in functionality (example one works in all versions and two works only in version 8 and higher): Example 1: myTotal = myTotal +3 Example 2: myTotal += 3 This is common in JavaScript, ActionScript, and many other languages. This syntax was added in ColdFusion version 8. We change the application-based setting because sessions are hidden from one another and cannot see each other. Therefore, we use the application CFC to either count or add a count every time a new session starts. Request start method—onRequestStart() This is one of the longest methods in the article. The first thing you will notice is that the script that is called is passed to the onRequestStart() method by ColdFusion. In this example, we will instruct ColdFusion to block any scripts from execution that begin with an underscore when called remotely. This means that you can call the server and request any .cfm page or .cfc page with an underscore at the start, and this protects it from being called outside the local server. The files can still be run if called from pages inside the server. This makes all these files locally accessible: <cffunction name="onRequestStart" output="false"> <cfargument name="thePage" type="string" required="true"> <cfscript> var myReturn = true; //fancy code to block pages that start with underscore if(left(listLast(arguments.thePage,"/"),1) EQ "_") { myReturn = false; } // update application stat on each request application._stat.lastHit = application._stat.thisHit; application._stat.thisHit = now(); application._stat.hits += 1; // update session stat on each request session._stat.lastHit = session._stat.thisHit; session._stat.thisHit = now(); session._stat.hits += 1; </cfscript> <cfreturn myReturn></cffunction> The methods in the following sections are used to update all the application and session statistics variables that need to be updated with each request. You should also notice that we are recording the last time the application or session was requested. The end methods Previously, some of the methods in this object were impossible to achieve with the earlier versions of ColdFusion. It was possible to code an end request function, but only a few programmers made use of it. We find that by using this object many more people are taking advantage of these features. The new methods that are added have the ability to run code specifically when a session ends, and when an application ends. This allows us to do things that we could not do previously. We can keep a record of how long a user is online without having to access the database with each request. When the session starts, you can store it in the session scope. When the session ends, you can take all that information and store it in the session log table if logging is desired in your site. Request end method—onRequestEnd() We are not going to use every method that is available to us. As we have the concept from the other sections, this would be redundant. The concepts of this method are very similar to the onRequestStart() method with the exception that it occurs after the requested page has been called. If you create content in this method and set the output attribute to true, then it will be sent back to browser requests. Here you can place the code that logs information about our requests: <cffunction name="onRequestEnd" returnType="void" output="false"> <cfargument name="thePage" type="string" required="true"></cffunction> Session end method—onSessionEnd() In the session end method, we can perform logging functions for analytical statistics that are specific to the end of a session if desired for your site. You need to use the argument's scope variables to read both the application and session variables. If you are changing application variables as in our example code, then you must use the argument's scope for that. <cffunction name="onSessionEnd" returnType="void" output="false"> <cfargument name="SessionScope" type="struct" required="true"> <cfargument name="ApplicationScope" type="struct" required="false"> <cfscript> // NOTE: You must use the variable scope below to access the // application structure inside this method. arguments.ApplicationScope._stat.sessions -= 1; </cfscript></cffunction> Application end method—onApplicationEnd This is our end method for applications. Here is where you can do the logging activity. As in the session method, you need to use the argument's scope in order to read variables for the application. It is also good to note that at this point, you can no longer access the session scope. <cffunction name="onApplicationEnd" returnType="void" output="false"> <cfargument name="applicationScope" required="true"></cffunction> On Error method—onError() The following code demonstrates how we can be flexible in managing errors sent to this method. If the error comes from Application.cfc, then the event (or method that had an issue) will be contained in the value of the arguments.eventname variable. Otherwise, it will be an empty string. In our code, we change the label on our dump statement, so that it is a bit more obvious where it was generated. <cffunction name="onError" returnType="void" output="true"> <cfargument name="exception" required="true"> <cfargument name="eventname" type="string" required="true"> <cfif arguments.eventName NEQ ""> <cfdump var="#arguments.exception#" label="Application core exception"> <cfelse> <cfdump var="#arguments.exception#" label="Application exception"> </cfif></cffunction>
Read more
  • 0
  • 0
  • 5086

article-image-flash-10-multiplayer-game-lobby-and-new-game-screen-implementation
Packt
27 Jul 2010
5 min read
Save for later

Flash 10 Multiplayer Game: The Lobby and New Game Screen Implementation

Packt
27 Jul 2010
5 min read
(For more resources on Flash and Games, see here.) The lobby screen implementation In this section, we will learn how to implement the room display within the lobby. Lobby screen in Hello World Upon login, the first thing the player needs to do is enter the lobby. Once the player has logged into the server successfully, the default behavior of the PulseGame in PulseUI is to call enterLobby API. The following is the implementation within PulseGame: protected function postInit():void { m_netClient.enterLobby();} Once the player has successfully entered the lobby, the client will start listening to all the room updates that happen in the lobby. These updates include any newly created room, any updates to the room objects, for example, any changes to the player count of a game room, host change, etc. Customizing lobby screen In the PulseUI, the lobby screen is the immediate screen that gets displayed after a successful login. The lobby screen is drawn over whatever the outline object has drawn onto the screen. The following is added to the screen when the lobby screen is shown to the player: Search lobby UI Available game rooms Game room scroll buttons Buttons for creating a new game room Navigation buttons to top ten and register screens When the lobby is called to hide, the lobby UI elements are taken off the screen to make way for the incoming screen. For our initial game prototype, we don't need to make any changes. The PulseUI framework already offers all of the essential set of functionalities of a lobby for any kind of multiplayer game. However, the one place you may want to add more details is in what gets display for each room within the lobby. Customizing game room display The room display is controlled by the class RoomsDisplay, an instance of which is contained in GameLobbyScreen. The RoomsDisplay contains a number of RoomDisplay object instances, one for each room being displayed. In order to modify what gets displayed in each room display, we do it inside of the class that is subclassed from RoomDisplay. The following figure shows the containment of the Pulse layer classes and shows what we need to subclass in order to modify the room display: In all cases, we would subclass (MyGame) the PulseGame. In order to have our own subclass of lobby screen, we first need to create class (MyGameLobbyScreen) inherited from GameLobbyScreen. In addition, we also need to override the method initLobbyScreen as shown below: protected override function initLobbyScreen():void { m_gameLobbyScreen = new MyGameLobbyScreen();} In order to provide our own RoomsDisplay, we need to create a subclass (MyRoomsDisplay) inherited from RoomsDisplay class and we need to override the method where it creates the RoomsDisplay in GameLobbyScreen as shown below: protected function createRoomsDisplay():void { m_roomsDisplay = new MyRoomsDisplay();} Finally, we do similar subclassing for MyRoomDisplay and override the method that creates the RoomDisplay in MyRoomsDisplay as follows: protected override function createRoomDisplay (room:GameRoomClient):RoomDisplay { return new MyRoomDisplay(room);} Now that we have hooked up to create our own implementation of RoomDisplay, we are free to add any additional information we like. In order to add additional sprites, we now simply need to override the init method of GameRoom and provide our additional sprites. Filtering rooms to display The choice is up to the game developer to either display all the rooms currently created or just the ones that are available to join. We may override the method shouldShowRoom method in the subclass of RoomsDisplay (MyRoomsDisplay) to change the default behavior. The default behavior is to show rooms that are only available to join as well as rooms that allow players to join even after the game has started. Following is the default method implementation: protected function shouldShowRoom(room:GameRoomClient):Boolean { var show:Boolean; show = (room.getRoomType() == GameConstants.ROOM_ALLOW_POST_START); if(show == true) return true; else { return (room.getRoomStatus() == GameConstants.ROOM_STATE_WAITING); }} Lobby and room-related API Upon successful logging, all game implementation must call the enterLobby method. public function enterLobby(gameLobbyId:String = "DefaultLobby"):void You may pass a null string in case you only wish to have one default lobby. The following notification will be received again by the client whether the request to enter a lobby was successful or not. At this point, the game screen should switch to the lobby screen. function onEnteredLobby(error:int):void If entering a lobby was successful, then the client will start to receive a bunch of onNewGameRoom notifications, one for each room that was found active in the entered lobby. The implementation should draw the corresponding game room with the details on the lobby screen. function onNewGameRoom(room:GameRoomClient):void The client may also receive other lobby-related notifications such as onUpdateGameRoom for any room updates and onRemoveGameRoom for any room objects that no longer exist in lobby. function onUpdateGameRoom(room:GameRoomClient):voidfunction onRemoveGameRoom(room:GameRoomClient):void If the player wishes to join an existing game room in the lobby, you simply call joinGameRoom and pass the corresponding room object. public function joinGameRoom(gameRoom:GameRoomClient):void In response to a join request, the server notifies the requesting client of whether the action was successful or failed via the game client callback method. function onJoinedGameRoom(gameRoomId:int, error:int):void A player already in a game room may leave the room and go back to the lobby, by calling the following API: public function leaveGameRoom():void Note that if the player successfully left the room, the calling game client will receive the notification via the following callback API: function onLeaveGameRoom(error:int):void
Read more
  • 0
  • 0
  • 4931

article-image-yui-28-menus
Packt
26 Jul 2010
9 min read
Save for later

YUI 2.8: Menus

Packt
26 Jul 2010
9 min read
(For more resources on YUI, see here.) Common navigation structures All but the most limited of websites must have a mechanism by which visitors can navigate around the pages of the site from the home page. In order to meet accessibility guidelines, several methods of navigation will usually be available, including at least a navigation menu and a site map. There have been many different implementation styles that have been popular over the years. Before anyone really worried about accessibility or standards compliance, a common way of designing a navigation menu was to use a series of images that linked to other pages of the site, and there was also the popular frame-based navigation structure. While these methods saved the designer a lot of time, effort, and any real skill, they led to hugely increased page load times and a legacy of bad coding practice. Thankfully, those days have long since passed, and with the continued development of CSS, it's now possible to design an effective navigation structure based on semantic HTML and styled with CSS. Designing a navigation menu that is effective, robust, and presented effectively can still pose a challenge, and troubleshooting the compatibility of a menu between different browsers can be a very time-consuming process. This is where the YUI steps in. Instant menus—just add water (or a Menu Control) The Menu Control is used to add one of several different menus to your website, saving you the chore of adding this almost essential feature yourself. It's another control that takes a complex, difficult, or time-consuming task, and one which is an almost inherent requirement of any website, and packages it up into a convenient and easy-to-use module. The three different types of menu you can create are: A standard navigation menu An application-style menu bar A right-click context menu The navigation menu can be implemented as either a vertical or horizontal menu and generates a clean and attractive interface, which your visitors can use to navigate to different areas of your site. The navigation model of any site is key to whether using the site is easy and enjoyable; nothing turns off visitors more than a poorly designed or inconsistent navigation structure. Another type of menu that the Menu Control is able to create is an application-style menu bar, which stretches across the screen horizontally, building on the current trend in the online world to blur the distinction between the browser and the desktop. As well as taking care of navigation for you, it can also be used to add right-click context (pop-up) menus to any part of your web application, which again can give a web application a definite desktop feel to it. The Menu Control is very flexible and can be built from existing HTML markup using a clean and logical list structure, or it can be generated entirely through JavaScript and built at runtime. Each of the different menu types is also given a default appearance with the sam skin so there is very little that is required to generate the attractive and highly functional menus. We'll be looking at implementing each of the different types of menu ourselves in just a moment. Before we do this, let's take a quick look at the classes that go together to make the Menu Control. The Menu classes This component is made up of a small family of different types of menu. There is a range of different classes that work together to bring the functionality of the different types of menu to you. The three main classes behind the Menu family are: YAHOO.widget.Menu YAHOO.widget.ContextMenu YAHOO.widget.MenuBar Menu is a subclass of Overlay, part of the Container family, and the other two are subclasses of Menu. Just as each TabView is made of several Tabs, each kind of Menu has a different class for its items: YAHOO.widget.MenuItem YAHOO.widget.ContextMenuItem YAHOO.widget.MenuBarItem ContextMenuItem is simply an alias for MenuItem created just for the sake of symmetry. All types of menu items can have a Menu as a submenu; neither ContextMenu nor MenuBar can be nested in a menu item, they are only good at the outermost level. All the menus are coordinated by YAHOO.widget.MenuManager, which listens to events at the document body level and dispatches them to the corresponding menus or menu items using the technique of Event Delegation to the limit; after all, the document body is the furthest out an event can bubble. Like the other members of the Container family, the constructor for Menu and its subclasses take two arguments; first a reference to existing markup or, if built via code, the id we want the Menu to have once rendered. The second argument takes the configuration options, if any, and accepts any configuration attribute as would be expected. However, in Menu, it can also take a couple of properties: itemData and lazyLoad, while MenuItem can also take value. We will see what they can be used for shortly. Menus can be built from existing markup or from code or any combination of both. The required markup for a Menu might seem a little complicated at first but it is intended to work in older clients or for users without JavaScript enabled. This, we know, is called Progressive Enhancement and Menu supports it very well; the CSS style sheet for Menu works whether JavaScript is active or not and by using the correct class names the Menus will look just the same for all our visitors regardless of the capabilities of their browsers. The markup will usually consist of a series of unordered lists <ul>, each of their list items <li> containing an anchor element <a> that leads to the next non-JavaScript enhanced page and optionally followed by a further nested unordered list. Menus will also read <select> elements creating a MenuItem for each <option>. When building a Menu from code, we may create and add each individual MenuItem to the Menu or we may use the itemData configuration option we've just mentioned, which takes an object literal with the description of the whole Menu at once. This is particularly handy for ContextMenus as they hardly make any sense without JavaScript enabled. Just as with any container, Menus have to be rendered. ContextMenus are usually rendered into document.body, as they have no place in the normal flow of the page. If the menu structure is too complex and takes too long to render, the lazyLoad option tells the Menu to render just the first level of items, those that would be visible initially, postponing rendering the rest until needed. Menu subclasses The ContextMenu is a specialized version of the control that provides a menu hidden from view until the element that it is associated with (the trigger element) is clicked with the right mouse button (except in Opera on Windows and OS X which requires the left-click + Ctrl key combination). The trigger element is defined using the trigger configuration attribute; this is the only configuration attribute natively defined by the ContextMenu class, all others are inherited. The MenuBar is similar to the standard Menu, but is horizontal instead of vertical. It can behave like an application-style menu bar, where the top-level menu items must be clicked in order for them to expand, or it can behave more like a web menu where the menu items expand on a simple mouse over and have submenu indicators. This is controlled with the autosubmenudisplay Boolean configuration attribute. The MenuItem class Each menu type has a subclass representing the individual menu items that form choices within the menu. They will be created automatically when a Menu is built from existing markup or by setting the itemData configuration option to a menu description. You will only create individual MenuItems when extending the functionality of an existing menu. MenuItems have several interesting configuration attributes: checked: Shows a checkmark to the left of the label, useful for items that toggle in between two states. classname: Added to the existing if any further styling is required. It can read this from existing markup. disabled: This item cannot be selected and will be grayed out. When built from markup, it can read this attribute from an tag. keylistener: The key combination (Shift, Control, or Alt + character) that will trigger this item. It can be read from markup. onclick: The method to be called when this item is clicked. text: A string to be shown in the label. url, target: The destination page for this item when not handled via code. selected: The item shows highlighted. submenu: A nested instance of Menu, an object description of a nested Menu, or a reference to the markup that would produce it. value: A value associated with this item. MenuItem subclasses The two subclasses YAHOO.widget.ContextMenuItem and YAHOO.widget. MenuBarItem both extend the MenuItem class, providing a constructor and some basic properties and methods for programmatically working with individual ContextMenu or MenuBar menu items. As a matter of fact ConextMenuItem is simply an alias for MenuItem. MenuBarItem has different defaults than MenuItem to suit the different layout of the MenuBar. Creating a Basic Navigation Menu Let's put together a basic navigation menu. Our menu will be built from underlying HTML rather than from script. We'll be enhancing the example of the image portfolio by first providing a landing, home page that will welcome us. We'll later add a context menu to the image portfolio itself so that instead of adding an extra button (like Rate!) for each option, we'll handle them via menus. Once complete, our landing page should appear like this:
Read more
  • 0
  • 0
  • 1541

article-image-security-plone-sites
Packt
26 Jul 2010
6 min read
Save for later

Security in Plone Sites

Packt
26 Jul 2010
6 min read
Download code from here More about securityFor a closer look at a variety of Plone-related security information, visit http://plone.org/products/plone/security/overview.For Erik Rose and Steve McMahon's excellent Plone Conference 2008 talk, visit http://plone.org/events/conferences/2008-washington-dc/agenda/securing-zope-and-plone-against-the-big-bad-internet/. Restricting TCP/IP access to localhost or LAN host One of the simplest things we can do to secure our system is to operate our Zope 2 instances only on the IP addresses that they are required to listen on. In most cases, it is 127.0.0.1 (or localhost, as it is commonly referred to) but it can also be a LAN host that is a private, non-routable IP address used only on your local area network (LAN). In this article, we will not cover LAN hosts. However, we suggest you consider using them when you need to access instances from another host on the LAN; otherwise, just use localhost. In the case of LAN hosts, once confgured, they will protect ports from being accessed by the outside world (that is Internet). However, it will allow them to be accessible from the LAN where you may want to confgure monitoring, for example via Munin , Zenoss (http://community.zenoss.org), and so on. What we will cover is how to use the localhost IP address. In 07-security-localhost.cfg, we have: [buildout]extends = 06-deployment-optimization-munin.cfg[instance1]http-address = 127.0.0.1:8081[instance2]http-address = 127.0.0.1:8082 You will notice we have re-configured the http-address parameter to include the entire HTTP address and not just the port number. You will also notice we have used the private, non-routable localhost address 127.0.0.1. Now run Buildout: $ bin/buildout -c 07-security-localhost.cfg Afterward, in parts/instance1/etc/zope.conf, you should see: ...<http-server> # valid keys are "address" and "force-connection-close" address 127.0.0.1:8081 # force-connection-close on # You can also use the WSGI interface between ZServer and ZPublisher: # use-wsgi on </http-server> This means that our instances will listen for connections only on 127.0.0.1; any attempt to connect from another host will fail. More about localhostFor more information about how the localhost really works, visit http://en.wikipedia.org/wiki/Localhost. For our purpose though, we can think of running the Plone site on localhost as "having a party that only your laptop or development workstation can join". Managing IP addresses and ports effectively As your production configuration grows, it may become more diffcult to manage a large number of IP addresses and ports. As such, it is often helpful to have them defned in their own part. In 07-security-ports.cfg, we have: [buildout]extends = 07-security-localhost.cfg[hosts]localhost = 127.0.0.1[ports]instance1 = 8081instance2 = 8082 Notice that we are not using these definitions for anything yet. But we can use them like this: ${hosts:localhost}:${ports:instance1}${hosts:localhost}:${ports:instance2} Effectively from now on, we have to change IP addresses and port numbers only in one place (assuming we change all static references such as 127.0.0.1:8080 to the new syntax). Configuring the Zope 2 effective user dynamically Another simple thing we can do to secure our system is to operate our Zope 2 instances with only those operating system users who have enough permission to execute the instances. In fact, Zope 2 will not run as root on UNIX-like systems. However, we frequently forget to do this. More importantly, sometimes we want to be more explicit with our configuration. This is where the effective-user parameter comes in handy. If no effective user is set, then Zope 2 will run as whoever executes the process. You could set the effective-user manually or you could use the gocept.recipe.env recipe (http://pypi.python.org/pypi/gocept.recipe.env) to set it. In the case of manual configuration, you may find it tedious to test your production configuration on systems that do not have the desired effective user (or you may not; this is mostly subjective). In the case of no configuration, you may find it annoying to be reminded that you cannot run Zope 2 as root when you get to production (or you may not; this is also subjective). In any event, we can formalize the configuration and automate the username selection process as follows. In 07-security-effective-user.cfg, we have: [buildout]extends = 07-security-ports.cfgparts += env[env]recipe = gocept.recipe.env[instance1]effective-user = ${env:USER}[instance2]effective-user = ${env:USER} Now run Buildout. $ bin/buildout -c 07-security-effective-user.cfg Afterward, in parts/instance1/etc/zope.conf you should see: ...effective-user aclark... This technique has several subtle, but important advantages over manual, or no configuration: The effective user is always set, so even if you try to start Zope 2 as root, it will run as the effective user The effective user is set to the user that runs the buildout, which means you can change the effective user easily The ${env:USER} variable can be used to configure user settings for additional services such as Pound, Varnish, and so on. Installing Cassandra to audit through the web (TTW) security If you ask anyone familiar with Plone about the permissions settings in the Security part of the Zope Management Interface, you are likely to get the following response: "DO NOT TOUCH!" That is because with so many possible permutations of settings, it is almost impossible to manage them all effectively by pointing and clicking. The next thing out of their mouth is likely to be: "USE WORKFLOW INSTEAD!" That is because Plone's workfow feature provides a much better way to effectively manage large amounts of permission changes. However, people do not always use workfow. They point and click away anyway, despite the warnings. You, however, have been warned. It is much better to manage permissions with workfow as compared to pointing and clicking on Permissions in the ZMI. Permissions and roles in the ZMI If you do not believe me, consider this. If you browse to http://localhost:8080/Plone and click on Site Setup | Zope Management Interface | Security, you will see almost two hundred permissions that look like the following (first ten): Next to each group of 10 permissions are checkboxes that correspond to the possiblerole assignments: Hopefully, enough has been said. The point again is two-fold: The ZMI opens the gateway to enormous complexity (categorically, not just with roles and permissions) In the case of roles and permissions, managing this complexity is best left to workfow (in which case, role-to-permission mappings are configured by the state) Roles and groups Similarly, the same Plone folks will often remind you to assign roles to groups and not users, and put users in groups to enable them to perform various tasks. They might say: "DO NOT ASSIGN ROLES TO INDIVIDUAL USERS!" This may be followed by: "ASSIGN THEM TO GROUPS INSTEAD!" Why? This is because to manage intricacies such as which user can perform which tasks and where, you are better off using the right tool for the job, that is adding users to groups with proper role assignments. Unfortunately, end users are still able to assign roles to individual users if they really want to via the Sharing tab or Local roles form in the ZMI. So, it is the site manager's responsibility to make sure they do not, to avoid having a site littered with individual role assignments.
Read more
  • 0
  • 0
  • 1480
Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at €18.99/month. Cancel anytime
article-image-through-web-theming-using-python
Packt
26 Jul 2010
2 min read
Save for later

Through the Web Theming using Python

Packt
26 Jul 2010
2 min read
Download code from here (Read more interesting articles on Plone here.) Examining themes in the Zope Management Interface Now that we have seen in part how themes work, let us take a closer look at their representation in Zope Object Database (ZODB). Browse to http://localhost:8080/Plone. Click on Site Setup Zope Management Interface| and you should see: This is a Through the Web (TTW) representation of all the objects in the database at the Plone site level (the application root is one level above). The most frequently used theme-related objects here are: portal_css portal_javascripts portal_skins portal_view_customizations Of these, portal_css and portal_javascripts are most often used to enable their respective debug modes, wherein the CSS and JavaScript files are not compiled into a single file (not to be confused with Zope 2's debug mode which detects filesystem changes in real time when enabled). Take a look at your site with Firebug, in particular the style tab. You should see: Now enable debug mode in portal_javascripts and look again. You should see: When portal_css debug mode is enabled, we can see (or by viewing the HTML source) that the CSS files are loaded individually in Firebug. The same applies to portal_javascripts debug mode. This can be absolutely invaluable when trying to correlate various visual elements with their respective sources. In addition to debug mode, you can also add CSS/JavaScript files to their respective registries through the Web, which brings us to the next topic.
Read more
  • 0
  • 0
  • 6381

article-image-introduction-applicationcfc-object-and-application-variables-coldfusion-9
Packt
26 Jul 2010
9 min read
Save for later

Introduction to the Application.cfc Object and Application Variables in ColdFusion 9

Packt
26 Jul 2010
9 min read
(For more resources on ColdFusion, see here.) Life span Each of our shared scopes has a life span. They come into existence at a given point, and cease to exist at a predictable point. Learning to recognize these points is very important. It is also the first aspect of "Scope". The request scope is created when a request is made to your ColdFusion server from any source. This could either be a web browser, or any type of web application that can make an HTTP request to your server. Any variable placed into the request structure persists until the request processing is complete. Variable persistence is the property of data remaining available for a set period of time. Without persistence, we would have to make information last by passing all the information from one web page to another, in all forms and in all links. You may have heard people say that web pages are stateless. If you have passed all the information into the browser, they would be closer to stateful applications, but would be difficult to manage. In this article, we will learn how to create a stateful web application. Here is a chart of the "life spans" of the key scopes: Scope Begins Ends Request Begins when a server receives a request from any source.Created before any session or an application is created. Ends when the processing for this request is complete.Ending has nothing to do with the end of applications or sessions. Application Begins before a session but after the request.Begins only when an Application.cfc file is first run with the current unique application name, or when the <cfapplication> tag is called in older code CF applications. Ends when the amount of time since a request is greater than the expiration time set for the application. Session Begins after an application is created.Created inside the same sources as the application. Ends when the amount of time since a request is greater than the expiration time set for the session. Client Begins when a unique visitor first visits the server. If you want them to expire, you can store client variables in encrypted cookies. Cookies have limited storage space and are not always available. We will be discussing the scopes in more detail later in this article series. All the scopes, except the client scope, expire if you shut down your server. When we close our browser window or reboot the client side, a session does not come to an end, but our connectivity to that particular session scope ends. The information and resources for storing that session are held until the session expires. Then, when connecting the server starts a new session and we are unable to reconnect to the former session. Introducing the Application.cfc object The first thing we need to do is to understand how this application page is called. When a .cfm or .cfc file is called, the server looks for an Application.cfc file in the current directory where the web page is being called from. It also looks for an Application.cfm file. We do not create an application or session scope with the .cfm version because .cfc provides many advantages and is much more powerful than the .cfm version. It provides better encapsulation and code reuse. If the application file is found, ColdFusion runs it. If the file is not found, then it moves up one directory towards the sever root directory in order to search for an Application.cfc file. The search stops either when a file is found, or once it reaches the root directory and a file is not found. There are several methods in the Application.cfc file. It is worth noting that this file does not exist by default, the developer must create it. The following table gives the method names and the details as to when those methods are called: Method name When a method is called onApplicationEnd The application ends; the application times out. onApplicationStart The application first starts: the first request for a page is processed or the first CFC method is invoked by an event gateway instance, a web service, or Macromedia Flash Remoting CFC. onCFCRequest HTTP or AMF (remote special Flash) calls. onError An exception occurs that is not caught by a try or catch block. onMissingTemplate ColdFusion receives a request for a non-existent page. onRequest The onRequestStart() method finishes(this method can filter request contents). onRequestEnd All pages in the request have been processed. onRequestStart A request starts. onSessionEnd A session ends. onSessionStart A session starts. onServerStart A ColdFusion server starts. When the Application.cfc file runs for the first time, these methods are called in the order as shown in the following diagram. The request variable scope is available at all times. Yet, to make the code flow right, the designers of this object made sure of the order in which the server runs the code. You will also find that for technical reasons, there are some issues that arise when we use the onRequest() method. Therefore, we will not be using this method. The steps in the previous screenshot are explained as follows: Browser Request: The browser sends a request to the server. The server passes the processing to the Application.cfc file, if it exists. It skips the step if it does not exist. The Application.cfc file has methods that execute if they exist too. The first method is onApplicationStart(). This executes on the basis of the application name. If the unique named application is not currently running on the server, then this method is called. Application Start: The next thing that Application.cfc does is to check if the request to the server is a pre-existing application. If the request is to an application which has not started, then it calls the onApplicationStart() method, if the method exists. Session Start: On every request to the server, if the onSessionStart() method exists, then it is called at this particular point in the processing. Request Start: On every request to the server, if the onRequestStart() method exists, then it is called at this particular point in the processing. OnRequest: This step normally occurs after the onRequestStart() method. If the onRequest() method was used, then by default it prevented the calling of CFCs. We do not say that it is always wrong to use this method. However, we will avoid it as much as possible. Requested Page: Now, the actual page requested is called and processed. Request End: After the requested page is processed, the control is passed back to the onRequestEnd() method, if it exists in Application.cfc. return response to browser: This is the point when ColdFusion has completed its work of processing information to respond to the browser request. At this point, you could either send HTML to the browser, a redirect, or any other response. Session End: The onSessionEnd() method is called if the method exists but only when the time since the user has last made a request to the server is less than the time for the session timeout. Application End: The onApplicationEnd() method is called if it exists when the time since the last request was received by the server is greater than the timeout for the application. The application and session scopes have already been created on the server and they do not need to be reinitialized. Once the application is created and other requests are made to the server, the following methods are called with each request: onRequestStart() onRequest() onRequestEnd() In previous versions of ColdFusion, when the onRequest() method of the Application.cfc was called, it blocked CFCs from operating correctly. You may see some fancy code in older frameworks that check if the current request is calling a CFC. They would then delete the onRequest() method for that request. Now there is a new method called onCFCRequest(). If you need backwards capability to previous versions of ColdFusion, then you would delete the onRequest() method. You can use either of these approaches depending on whether you need the code to run on prior versions of ColdFusion. The onCFCRequest() method will execute at the same point as the onRequest() method in the previous examples. You can add this code in or not depending on your own preferences. The previous example still operates as expected if you leave the method out. The OnRequestEnd.cfm side of using Application.cfm based page calls does not execute if the page runs a <cflocation> tag before the OnRequestEnd.cfm is run. It is also not a part of Application.cfc based applications and was intended for use with Application.cfm in older versions of ColdFusion. Here is a representation of the complete process that is less granular. We can see that the application behaves just as it did in the earlier illustration; we just do not go into explicit detail about every method that is called internally. We also see that the requested page can call additional code segments. These code segments can be a CFC, a custom tag, or any included page. Those pages can also include other pages, so that they create a proper hierarchy of functionality. Always try to make sure that functionality is layered, so the separation of layers provides a structured and simpler approach to creation, maintenance, and long-term support for your web applications. The variables set in Application.cfc can be modified before the requested page is called, and even later. Let us say for example, you want to record the time at which the session was last hit. You could choose to set a variable, <cfset session._stat.lasthit = now()>. This could be set either at the beginning of a request, or at the end. Here, the question is where you would put this function. At first, you might think that you would add this function to the OnSessionStart() method or OnSessionEnd() method. This would cause an issue because these two methods are only called when a session has begun or when it has come to an end. You would actually put the code into the OnRequestStart() or OnRequestEnd() code segment of the Application.cfc file for the function to work properly. The request methods are called with every server request. We will have a complete Application.cfc to use as a model for creating our own variations in future projects. Remember to place the code in the right place and test your code using CFDump or by some other means to make sure it works when creating changes.
Read more
  • 0
  • 0
  • 5113

article-image-removing-unnecessary-jquery-loads
Packt
23 Jul 2010
7 min read
Save for later

Removing Unnecessary jQuery Loads

Packt
23 Jul 2010
7 min read
The first thing that you should always do before making any changes is take a backup of your site. You can do this manually or by using an extension like Akeeba backup, which can be found in the JED or at the following link: http://extensions.joomla.org/extensions/access-a-security/backup/1606 Having a backup copy is essential to restore a working copy of our site if a mistake is made. Also, you may be wondering whether, later, if you install a newer version of the extension, you may lose all of the changes made. This can happen; therefore, we have made these modifications after we have finished installing the extensions we need. But don't worry too much about that. You won't be installing a newer version of an extension every day. Mostly, you will install a newer version of the extension if bugs have been found or if the version introduces some features you want. Otherwise, if the site is working nicely and there are no bugs or newer features, we don't need to update these extensions. Anyway, the most important thing to remember is to backup. Always keep a backup of your work. As mentioned earlier, each one of the extensions that we are using is loading its own jQuery library, and thus makes our site needlessly load the library many times. This makes our site download more files than are really necessary. Just take a look at the source code of your site. In the head section we can see the script tags that are loading the required libraries: <script type="text/javascript" src="/plugins/system/cdscriptegrator/libraries/jquery /js/jsloader.php?files[]=jquery-latest.packed.js&amp;files[]= jquery-noconflict.js"></script> <script type="text/javascript" src="/plugins/system/cdscriptegrator/libraries/jquery/ js/ui/jsloader.php?file=ui.core"></script> <script type="text/javascript" src="/plugins/system/scjquery/js/jquery-1.3.2.min.js"></script> <script type="text/javascript" src="/plugins/system/scjquery/js/jquery.no.conflict.js"></script> <script type="text/javascript" src="/plugins/system/scjquery/js/ jquery-ui-1.7.2.custom.min.js"></script> <script type="text/javascript" src="/media/system/js/mootools.js"></script> <script type="text/javascript" src="/media/system/js/caption.js"></script> <script type="text/javascript" src="/plugins/content/ppgallery/res/jquery.js" charset="utf-8"></script> <script type="text/javascript" src="/plugins/content/ppgallery/res/jquery.prettyPhoto.js" charset="utf-8"></script> <script type="text/javascript" src="http://wayofthewebninja.com/modules/ mod_ninja_shadowbox/ninja_shadowbox/js/adapter/ shadowbox-jquery.js"></script> <script type="text/javascript" src="http://wayofthewebninja.com/modules/ mod_ninja_shadowbox/ninja_shadowbox/js/shadowbox.js"></script> <script type="text/javascript" src="/modules/mod_ajaxsearch/js/script.js"></script> <script type="text/javascript" src="http://wayofthewebninja.com/modules/ mod_superfishmenu/tmpl/js/jquery.event.hover.js"></script> <script type="text/javascript" src="http://wayofthewebninja.com/modules/ mod_superfishmenu/tmpl/js/superfish.js"></script> <script type="text/javascript" src="http://wayofthewebninja.com/modules/ mod_c7dialogmod/jquery/ui.core.js"></script> <script type="text/javascript" src="http://wayofthewebninja.com/modules/ mod_c7dialogmod/jquery/ui.dialog.js"></script> <script type="text/javascript" src="http://wayofthewebninja.com/modules/ mod_c7dialogmod/jquery/ui.draggable.js"></script> <script type="text/javascript" src="http://wayofthewebninja.com/modules/ mod_c7dialogmod/jquery/ui.resizable.js"></script> Here we can see that lots of JavaScript files are being loaded, and some of them are repeated. Surely, that doesn't make our site load faster. Let's try to improve this as much as we can. We will use the SC jQuery plugin in order to load the jQuery library. With the help of a variable created by this library we can also determine if the jQuery library needs to be loaded or not. How is this done? If we open the plugins/system/scjquery.php file, at the very bottom of the file you can see the following code: $app->set( 'jquery', true ); In newer versions of the plugin this line of code seems to have been removed. However we can modify the plugins/system/scjquery.php file and add that line to it, at the very bottom, just like this: ... $app->set( ‘jquery’, true ); $doc->setHeadData($headData); return true; } } This way we will be able to use the techniques we are about to show.   This will set a variable jquery with the value true. Our next step is to use this variable to our benefit, just like we did in the ajaxSearch module. Open the modules/mod_ajaxsearch/mod_ajaxsearch.php file. We modified this file and it now appears as follows: $app =& JFactory::getApplication(); if( !$app->get('jquery') ){ $document->addscript(JURI::root(true).'modules'.DS. 'mod_ajaxsearch'.DS.'js'.DS.'jquery-1.3.2.min.js'); } First we need to get an instance of the global application object. We will then use the get method to try and read the 'jquery' variable. If this variable doesn't exist, it would mean that the SC jQuery plugin has not been loaded, and thus the jQuery library won't be present. If this happens, we will let the module load its own copy of the library. This helps us in reducing the number of times the library has been loaded. Now we are going to look into the other extensions that we used, seeing how we can solve each situation. Code highlight Remember the Core Design Chili Code plugin extension? We used it to reformat some code, as we can see in the next image: This plugin required the jQuery library, but as the plugin itself doesn't have the library included, another plugin from the same developers was needed—the Core Design Scriptegrator plugin. You can check it in Extensions | Plugin Manager: This plugins works much like the SC jQuery plugin, but for the extensions of the Core Design Chili Code plugin developers. This plugin loads the jQuery library, and some others that we don't need, in order for the other extensions to use it. As we are using the SC jQuery plugin, we can disable the Scriptegrator plugin: But hey, then the Core Design Chili Code plugin stops working. Why? We have said that the Chili Code plugin needs the jQuery library, but we are using the SC jQuery plugin to provide it. At this point we need to check the Chili Code plugin source code, so just open plugins/content/cdchilicode.php. Here we can see the following piece of code: // define language if (!defined('_JSCRIPTEGRATOR')) { Error::raiseNotice('', JText::_('CHILICODE_ENABLE_SCRIPTEGRATOR')); return; } // require Scriptegrator version 1.3.4 or higher $version = '1.3.4'; if (!JScriptegrator::versionRequire($version)) { JError::raiseNotice('', JText::sprintf('CHILICODE_SCRIPTEGRATOR_REQUIREVERSION', $version)); return; } if (!JScriptegrator::checkLibrary('jquery', 'site')) { JError::raiseNotice('', JText::_('CHILICODE_MISSING_JQUERY')); return; } What does all this code do? It checks for the Core Design Scriptegrator plugin. If it doesn't find any evidence of the plugin, it raises some errors and returns. We know that jQuery will be loaded. So we can comment the code mentioned, and the Chili Code plugin will work again. That's it; we have just reduced one jQuery library load; ready for the next one?
Read more
  • 0
  • 0
  • 2203

article-image-creating-theme-package-zopeskel
Packt
23 Jul 2010
4 min read
Save for later

Creating a theme package with ZopeSkel

Packt
23 Jul 2010
4 min read
(Read more interesting articles on Plone here.) Download code from here Creating a theme package with ZopeSkel Now that we have examined someone else's theme, let us try creating our own. Remember, we will not cover theme creation in depth; this is only a sample for site administrators (who may or may not be required to develop themes, in addition to managing their site). For more information about creating themes, Visit: http://plone.org/documentation/kb/how-to-create-a-plone-3-theme-product-on-thefilesystem. To create a theme, we will use the ZopeSkel tool (http://pypi.python.org/pypi/ZopeSkel) to generate some of the boilerplate code. ZopeSkel uses PasteScript (http://pypi.python.org/pypi/PasteScript) to facilitate package generation using a set of templates. Other options include: Write everything by hand from memory Copy the contents of another theme package Use another tool such as ArchGenXML to generate boilerplate code (http://plone.org/products/archgenxml) Adding ZopeSkel to a buildout Now let's add ZopeSkel to our buildout. In 03-appearance-zopeskel.cfg, we have this: [buildout] extends = 03-appearance-zopepy.cfg parts += zopeskel [zopeskel] recipe = zc.recipe.egg dependent-scripts = true We extend the previous working configuration file, and add a new section called zopeskel. This section uses the zc.recipe.egg recipe (http://pypi.python.org/pypi/zc.recipe.egg) to download ZopeSkel from the Python Package Index (zc.recipe.egg will search the Python Package Index for packages that match the section name zopeskel). We set dependent-scripts to true, to tell Buildout to generate Python scripts for ZopeSkel's dependencies such as PasteScript, which includes the paster script. Now stop Plone (with Ctrl + C or Ctrl + Z/Enter) and run Buildout: $ bin/buildout -c 03-appearance-zopeskel.cfg You should see: $ bin/buildout -c 03-appearance-zopeskel.cfg Uninstalling plonesite. Updating zope2. Updating fake eggs Updating instance. Installing plonesite. … Updating zopepy. Installing zopeskel. Getting distribution for 'zopeskel'. Got ZopeSkel 2.16. Getting distribution for 'Cheetah>1.0,<=2.2.1'. … Got Cheetah 2.2.1. Getting distribution for 'PasteScript'. Got PasteScript 1.7.3. Getting distribution for 'PasteDeploy'. … Got PasteDeploy 1.3.3. Getting distribution for 'Paste>=1.3'. … Got Paste 1.7.3.1. Generated script '/Users/aclark/Developer/plone-site-admin/ buildout/bin/ zopeskel'. Generated script '/Users/aclark/Developer/plone-site-admin/ buildout/bin/ paster'. Generated script '/Users/aclark/Developer/plone-site-admin/ buildout/bin/ easy_install'. Generated script '/Users/aclark/Developer/plone-site-admin/ buildout/bin/ easy_install-2.4'. You will notice that in addition to bin/zopeskel, Buildout also installed the "dependent scripts" bin/paster and bin/easy_install (the latter of which we do not really need in this case). Running ZopeSkel Now try running ZopeSkel with the command: $ bin/zopeskel You should see: Usage: zopeskel <template> <output-name> [var1=value] ... [varN=value] zopeskel --help Full help zopeskel --list List template verbosely, with details zopeskel --make-config-file Output .zopeskel prefs file ... This tells us we need to pick a template and output-name. ZopeSkel goes on to list the available templates. They are: archetype: A Plone project that uses Archetypes content types kss_plugin: A project for a KSS plugin plone: A project for Plone products plone2_theme: A theme for Plone 2.1 plone3_portlet: A Plone 3 portlet plone_app: A project for Plone products with a nested namespace plone_pas: A project for a Plone PAS plugin plone2.5_theme: A theme for Plone 2.5 plone3_theme: A theme for Plone 3 plone2.5_buildout: A buildout for Plone 2.5 projects plone3_buildout: A buildout for Plone 3 installation plone_hosting: Plone hosting: buildout with ZEO and Plone recipe: A recipe project for zc.buildout silva_buildout: A buildout for Silva projects basic_namespace: A basic Python project with a namespace package nested_namespace: A basic Python project with a nested basic_zope: A Zope project<
Read more
  • 0
  • 0
  • 2129
article-image-creating-your-first-blackberry-project
Packt
23 Jul 2010
14 min read
Save for later

Creating your First BlackBerry Project

Packt
23 Jul 2010
14 min read
(For more resources on BlackBerry, see here.) So, without any further words, let's get to work! Choosing the SDK version Remember that the first step is to choose the SDK version to use. For this project we want to choose the lowest possible SDK version, which is 4.2.1. This is because this application is so simple that it will not need to use any of the newer features of more recent versions of the SDK. By choosing a lower version, more models of handheld can be used to run this application. Conversely, choosing a higher SDK version means that fewer models of handhelds can run the application. Therefore, you should choose the lowest version of the SDK that still supports the features you require in order to support as many devices as possible. We will go through the steps of actually applying this later on, but for now, the choice is made and we are ready to move on. Creating a new project You need to create a new project for your new application. The IDE makes it very simple to get started, but because you are creating a BlackBerry project you have to be careful. Let's get started and see what I mean. Time for action – creating a new project You can create a new project by clicking on File | New | Project... option in the menu bar (not the File | Java Project menu item). The New Project dialog gives you many choices for which type of project to create. You want to create a BlackBerry project, of course. Expand the BlackBerry folder in the tree and then select the BlackBerry Project node. When that is done click on the Next button. Enter TipCalc as the name of the application and click on the Finish button to create the new project. What just happened? These three steps are all that is needed to create a BlackBerry project in Eclipse. You were told earlier that choosing New | Java Project was not the right thing to do. This is because the wizard that you get from choosing this menu item is the Swiss Army Knife wizard that will set up any kind of project for Eclipse. It is powerful, complicated, and not for beginners. Because of this, we just won't use it at all. The BlackBerry Project option is much easier to use, you just have to remember to use the New | Project... option instead of the New | Java Project option. Once you have chosen the right menu item, the New Project dialog is shown. Apparently, it is possible to have so many project types available that finding the one you want can be a challenge. The text field at the top of the dialog will filter the tree below to include only projects whose name matches the filter test. In our case though, the BlackBerry project is right near the top and easily accessible so there really isn't a need for the search feature. The last step of the wizard prompts you to enter the name of your new application. Project names are used as a directory name but are not used in code so they can have some special characters, such as a space, which would otherwise be invalid for code. If you try to provide a name that is invalid the wizard will show a warning about the name to indicate the name is not valid. Below the Project name text box is a checkbox indicating to use the default workspace location. By leaving the box checked the new project will be placed in a directory named after the project name under the directory set as the workspace. You can change the location where the new project files are stored by unchecking the Default location checkbox and then entering a new location in the edit field provided. Adding a package to the new project Next, you will create a new package for the application to use. A Java package is a container for the objects in your application and is used to prevent conflicts if the classes you create happen to have the same name as another class in the same project or even the system classes. Packages are equivalent to namespaces in C# and Visual Basic .NET (VB.NET). Adding a package to the project in this way is a minor housekeeping task, but is also an overall good technique because it forces you to choose your package name up front before creating any code. In Java, the naming convention for a package is to use your Internet domain name in reverse—almost like you were creating a new server. In this case, we will use the package name com.rimdev.demo.tipcalc. The package name can be any valid Java name and doesn't have to follow these conventions. Time for action – creating a new project Add the package by right-clicking on the src folder in the Package Explorer and then selecting New | Package. After selecting the menu the New Java Package wizard is shown. This small wizard is here only to collect the folder where the package files will be and the name of the package itself. Because you selected the src folder to begin with, that part is already filled in so you need to specify only the name of the package. Enter the package name com.rimdev.demo.tipcalc into the Name field and then click on Finish to create the package. What just happened? At this point you have an empty project that is ready to start being used. You've taken the BlackBerry application project that you had before and added a package to the src directory in preparation for creating the actual source files (which will come next). The project tree is expanded slightly to include the package you just created under the src directory—the directory whose icon looks like a little mail parcel. Creating a package in your project doesn't result in any actual source files being created. Instead, it sets up the project so that when you do create files later on they will be created with package definitions already included in them. Start at the beginning Every application must have a starting point, and for BlackBerry applications it is at a method named main. The use of the name main goes all the way back to the C programming language, if not further. At that time, simply making a method named main was enough to be able to run an application. However, because Java is an object-oriented language, you can't just make a method named main. In Java, all methods must be in a class, and this includes the method main as well. In addition to the main method all BlackBerry applications must contain an object derived from Application as well. As both the Application-derived class and the main method are required, it is standard practice to include the main method in the same class as your Application. Application and UiApplication As we just said, every BlackBerry application must contain a class derived from Application. The Application class contains the bare essentials for interacting with the BlackBerry operating system. If an application displays a User Interface (UI) then the bare essentials in the Application class are not enough. Instead, you should use UiApplication—the derived class that handles the special processing needed to interact with the user as well as the operating system. So, the next step is to create a class derived from UiApplication and that contains the main method to serve as the starting point of your BlackBerry application. Time for action – adding the UiApplication class To create this starting class right-click on the package you just created in the project and select New | Class. First, give the class a name; enter TipCalcApplication into the Name field. The next step is to set the superclass for your new class. The superclass is another name for a base class, or the class from which your new class will be derived. Eclipse offers a strong browser tool to quickly and easily find the class. Click on the Browse button next to the Superclass field . This dialog is aware of all of the classes in the libraries and allows you to choose the proper one. By default, the class java.lang.Object is set as the superclass. Replace java.lang.Object with uiapplication. Notice that as you do so, other class names appear in the list below, but once it is completely entered only the net.rim.device.api."ui.UiApplication" class is shown. Also notice that even though you entered the name in lowercase and did not enter the complete package name, the filter found the correct class with the correct casing. Click on OK to select this class. Back at the New Java Class dialog there is one more setting to make and that is to check the public static void main(String args[]) option. This creates a stub main function that is used to initiate the application. Use this checkbox only when creating UiApplication objects ; no other classes need them. Check the public static void main(String[] args) checkbox so the wizard will generate the main function. Finally, click on Finish and see the new class in the project. What just happened? You just created the first class for use in your new application! Well, to be more accurate you used Eclipse to set up a new class with some standard elements based on how you filled out the dialog. You could have done the same thing by simply creating a new file and manually adding all of the code by hand, but that's just not as interesting, is it? To be real though, the tools that Eclipse provides are truly helpful and easy to use. The New Java Class dialog that is displayed has many options that can be set and which will cause Eclipse to generate different code. Notice that the package name has already been supplied in the dialog because we started creating this class by right-clicking on the package name in the project. Also, the Source Folder is properly set already because you created the package inside the src folder previously. A closer look at the code Now, let's look at the code that was generated. package com.rimdev.demos.tipcalc;import net.rim.device.api.ui.UiApplication;public class TipCalcApplication extends UiApplication { /** * @param args */ public static void main(String[] args) { // TODO Auto-generated method stub }} The first line of code is the package declaration for com.rimdev.demos.tipcalc. This line defines the package where the TipCalcApplication class will reside. The package can be specified in the New Class dialog but because we previously added the package to the project, the package was supplied automatically to the new New Class dialog. package com.rimdev.demos.tipcalc; The next line is an import statement for net.rim.device.api.ui.UiApplication. Import statements are similar to .NET using or imports statements and declare which libraries are being used. The Java convention is to specifically import each class being referenced. It is possible to wildcard the import statement though, in which case the class name would be replaced with *, that is, net.rim.device.api.ui.*. When doing this all of the classes in that package will be imported into your application and this can make coding easier. It can certainly be annoying having to go back each time you want to use a new class and add the import statement for it. Eclipse is pretty smart and shouldn't include any classes unless they are actually being used when it compiles your application, so there shouldn't be any negative impact on performance. Having said all that, the established convention is not to use wildcarding because it also makes it less clear for someone looking at your application later on to know exactly which classes are being used. In the end, it is probably best to stay with the established convention, which we will do in this article. import net.rim.device.api.ui.UiApplication; Next, we have the class declaration itself. Again, notice that the extends keyword is already added and the class chosen to be the superclass, UiApplication, is added as well. These are added because we chose the UiApplication to be the superclass in the New Class dialog. public class TipCalcApplication extends UiApplication { Lastly, notice that the public static void main method is also created. Remember that every application must have a main method, and this is that method. The method was added because we checked the checkbox for it. Very simple and easy! The words public and static are special keywords that allow the main method to be called by the system before any of the objects in your application are created. public static void main(String[] args) { // TODO Auto-generated method stub} Time for action – expanding TipCalcApplication Now that you have the class created with some of the boilerplate code it's time to expand it and make the application actually do something. You can start off by giving the static main function something to do. Replace the main method with the following code. /** * @param args */public static void main(String[] args) { // TODO Auto-generated method stub // Create a new instance of the application. TipCalcApplication theApp = new TipCalcApplication(); // To make the application enter the event thread and startprocessing messages, // we invoke the enterEventDispatcher() method. theApp.enterEventDispatcher();} Secondly, you need to add the TipCalcApplication constructor to the class so add the following code. private TipCalcApplication(){ // Push the main screen instance onto the UI stack forrendering. pushScreen(new TipCalcMainScreen());} What just happened? The code that you just added takes the simple generated code that you got from the New Class wizard and expands it to set up and start the application. The first thing you did was to put some code in the initially empty main method. This code in the main function is used to actually create an instance of the application's object, which happens to contain the main method. This may seem strange unless you are used to it and understand what the static keyword means. If not, then just understand that static means that the main method can be called without an instance of the object that contains it. You still do need to create an instance of the application though, and so that's the first step. theApp = new TipCalcApplication(); The next line of code in the main method is the call to the enterEventDispatcher method on the application that you just created. This is a method already implemented in the UiApplication class. It does all of the setup necessary to get the application started, runs the application, and waits until the application is finished. theApp.enterEventDispatcher(); As we said earlier, an Application object is required, but it's the main function that is the actual entry point of the program. When the main function is exited the application is terminated and cleaned up by the operating system. The Application object, and more specifically the call to enterEventDispatcher, is why a class derived from Application is required. The last thing to do for this class is to create the constructor and show the first screen. We haven't created the screen yet, but we can go ahead and create the code to use it. The constructor is also very simple and does only one thing. You could do more in the setup and initialization of things in the application constructor of course (if your application needs it), but this simple application does not. Here we create a new instance of the TipCalcMainScreen class and then push it onto the UI stack. The TipCalcMainScreen is the class that you will create next and is the screen that you will display to the user. We will come back to pushScreen and the UI Stack later. pushScreen(new TipCalcMainScreen());
Read more
  • 0
  • 0
  • 5456

article-image-examining-themes-omelette-and-python
Packt
23 Jul 2010
3 min read
Save for later

Examining themes with Omelette and Python

Packt
23 Jul 2010
3 min read
Installing themes with Buildout For a lot of website projects, a theme downloaded from plone.org (http://plone.org/products) or the Python Package Index (http://pypi.python.org) is enough to launch a professional-looking site. If your project falls into this category, or if you just want to experiment, follow the steps in this chapter. Searching for themes on plone.org We will need to find a theme we like. We can do that by browsing to http://plone.org. Next, click on Downloads Add-on Product Releases | Themes|. You should see (result similar to): Click on a theme to view a screenshot and select one you like, for example beyondskins.ploneday.site2010, and add the package to your buildout.cfg file. Adding themes with Buildout In 03-appearance-wpd2010.cfg, we extend the last known working configuration file from Chapter 2, that is 02-site-basics-blog.cfg. It looks like this: [buildout]extends = 02-site-basics-blog.cfg[instance]eggs += beyondskins.ploneday.site2010zcml += beyondskins.ploneday.site2010 In addition to adding the package name to the eggs parameter, we must add it to the zcml parameter as well. Now stop Plone (with Ctrl + C or Ctrl +Z/Enter) and run: $ bin/buildout -c 03-appearance.cfgUpdating zope2.Updating fake eggsUpdating instance.Getting distribution for 'beyondskins.ploneday.site2010'.Got beyondskins.ploneday.site2010 1.0.3. Now start Plone: $ bin/instance fg Installing themes in Plone Browse to http://localhost:8080/Plone. Now, click on Site Setup Add/Remove Products| and you should see: Check the box next to WorldPloneDay: Theme for 2010 edition 1.0.3 and click on Install. Now browse to http://localhost:8080/Plone and you should see: This theme is the courtesy of Simples Consultoria (http://www.simplesconsultoria.com.br/). Thank you! You can examine the anonymous view (what everyone else sees) by loading http://127.0.0.1:8080/Plone in your browser (that is. by using the IP address instead of the hostname). You can also load either of these URLs (http://127.0.0.1:8080/Plone or http://localhost:8080/Plone) from another web browser (besides the one you are currently using) to see the anonymous view (for example, Safari or Internet Explorer, instead of Firefox). To display the blog entry to the public, we have transitioned the other objects in the site root to the private state. Examining themes with Omelette and Python Simply put, a theme is a collection of templates, images, CSS, JavaScript, and other files (such as Python scripts) that control the appearance of your site. Typically these files are packaged into a Python package, installed in your Plone site with the help of Buildout, and installed in Plone via the Add/Remove Products configlet in Site Setup. Once installed, certain elements of the theme can be edited through the Web using the ZMI. However, these changes only exist in the site's database. Currently there is no easy way to transfer changes made through the Web from the database to the filesystem; so there is a trade-off for performing such customizations through the Web. If you lose your database, you lose your customizations. Depending on your goals, it may not be entirely undesirable to store customizations in your database. But nowadays, most folks choose to separate their site's logical elements (for example themes, add-on functionality, and so on) from their site's content (that is data). Creating a filesystem theme and resisting the urge to customize it through the Web accomplishes this goal. Otherwise, if you are going to customize your theme through the Web, consider these changes volatile, and subject to loss.
Read more
  • 0
  • 0
  • 1901

article-image-customizing-prestashop-theme-part-1
Packt
22 Jul 2010
7 min read
Save for later

Customizing PrestaShop Theme Part 1

Packt
22 Jul 2010
7 min read
(For more resources on PrestaShop 1.3, see here.) The most basic level is using the back office panel to customize the layout. Using this knowledge, we can make some quick and easy changes without having any technical knowledge. If you need more advanced changes than what can be achieved here, you will need to edit the theme and the CSS files, which will be explained in the next article on Customizing PrestaShop Theme Part 2. It must be noted that all design changes that you can do in this back office can also be achieved through customization on the theme files (which involves editing of the file's markup) too. Although knowledge of this theme editing approach encased that of the back office setting, it is useful to know that there are reasons to choose the latter option with no "hacking" of scripts even if you are an advanced user as there could be some issues when you have to update to the next PrestaShop version. You will have to update some of these modified files as these changes may not be automatically included in the newer version. We have to decide what kind of layout we would want, just like the interior design space of a building that you are erecting, you need to visualize the spaces and how users will navigate your retail outlet. You will also need to know what kind of resources can help the successful function of your store, customers in real brick-and-mortar stores do not have to ask a lot of questions as they are prone to browsing the items while having the advantage of feeling, smelling, holding, or trying the items at the same time. While this is true for a real store/shop, the online store does not have this advantage. So, consider features/functions that can be a "replacement" to this disadvantage, such as a 30 day return policy. In a real shop, customers may ask questions at the customer service desks. The same thing can be done with your online store; you can add a lot of information that your customers may need while balancing it with a good design, navigation, and browsing experience. This will ensure that the customer finds the information and this reduces the need to repetitively answer the same queries. This is one of the main reasons why an online store exists, which means that information can be obtained easily 24x7. Therefore, in an online shop, you will have to decide on what kind of features you want to introduce, for example, one block for product information, another for customer service information where they can get information on return policy, how to make payment, and so on. This is just a background that is needed to decide the functions of your store. We will not be discussing about what makes a good navigation or whether one way can be more effective than another. We will learn about how you can use the knowledge about theming for PrestaShop-based stores to build your online store or if you are a web designer, your clients' online stores suitable with the stores' concepts. You will also learn how to go about in applying the necessary modules to complement your theme setup. Before we start this article, you should get acquainted with the back office panel. This will help you understand what we are exploring here. In this article, we will be sticking with the default PrestaShop theme and learn how to: Install, uninstall, enable, and disable module blocks in the center, left, and right columns. Transplant and position modules by moving them to columns and within the columns. The default layout Let's have a look again at your current storefront and how the theme is governed by the back office control panel. By looking at the screenshot, you can tell which back office items you need to modify, replace, or set according to your needs. The basic layout outline can be seen in the following screenshot: Besides the back office control over appearance, our theme is also affected by the modules that control the functionality of your store. At this stage, we will be working on the existing modules in PrestaShop. This is where you decide whether your site visitor will see the product categories, the top selling products, your product listing, the specials, your featured products, and so on. If you run an e-commerce store with a payment option that links automatically to a payment gateway, you may want to study a bit more about each of these modules as well. You will also notice that the default theme uses a three column layout with a header in the top block and a footer at the bottom. Through the back office panel, all the default blocks on the left and right columns can be moved or transplanted interchangeably. Some of the blocks in the header (top blocks) can be moved into the left column or right column. The featured product block and the editorial block, which are at the center column, are pretty much stuck in this position. Modules The Modules tab allows you to control the modules you want to use in the store. You will be able to transplant the modules and move them around according to the site navigation you want, considering some limitations at this stage. You can move them up or down in the columns. You may also position them in the left or the right column or you may disable them. You also have the option of adding a new module or choosing ones that are available from the PrestaStore. PrestaShop has some already installed modules, and the number of newly developed ones is growing every day. Now let's move on to Back Office | Modules, as shown in the following screenshot:     We will go into the listing and get some ideas on each one. However, we will focus in greater detail on the modules that affect theming directly. Among the existing modules in this version (PrestaShop 1.3.1), which are readily available for installation, some of them are: Advertisement – 1 module: Google Adsense. Products module – 6 modules: Cross selling, RSS products feed, Products Comments, Products Category, Product tooltips, Send to a Friend module. Stats Engines – 5 modules: Artichow, Google Chart, Visifire, XML/SWF Charts, ExtJS. Payment – 8 modules: Bank Wire, Cash on delivery (COD), Cheque, Google Checkout, Hipay, Moneybookers, Paypal, PaypalAPI. Tools – 14 modules (but only 12 modules listed): Birthday Present, Canonical URL, Home text editor, Customers follow-up, Google sitemap, Featured Products on the homepage, Customers loyalty and rewards, Mail alerts, Newsletter, Customer referral program, SMS Tm4b, and Watermark. Blocks – 23 modules: Block advertising, Top seller block, Cart block, Categories block, Currency block, Info block, Language block, Link block, Manufacturers block, My Account block, New products block, Newsletter block, Block payment logo, Permanent links block, RSS feed block, Quick Search block, Specials block, Suppliers block, Tags block, User info block, Footer links block, Viewed products block, Wish list block. Stats – 25 modules: Google Analytics, Pages not found, Search engine keywords, Best categories, Best customers, Best products, Best suppliers, Best vouchers, Carrier distribution, Catalog statistics v1.0, Catalog evaluation, Data mining for statistics, Geolocation, Condensed stats for the Back Office homepage, Visitors online, Newsletter, Visitors origin, Registered Customer Info, Product details, Customer accounts, Sales and orders, Shop search, Visits and Visitors, Tracking - Front office. You should also see an Icon legend on the right that reads the following: Apart from these three options of installing, enabling, and disabling, you may also add new modules using the button on the top-left corner of the module tab. There are also plenty of third party modules that can be used to make the store more interactive and attractive. Discussing about them is not within the scope of this article.
Read more
  • 0
  • 0
  • 3407
article-image-customizing-prestashop-theme-part-2
Packt
22 Jul 2010
13 min read
Save for later

Customizing PrestaShop Theme Part 2

Packt
22 Jul 2010
13 min read
(For more resources on PrestaShop 1.3, see here.) Let's move on with our next step. Of course, exploring every tab in the back office would be advantageous, but we will specifically touch only those points that will affect your theming process. We will now look at how we can modify the following: Logo Top of page Adding FEATURED PRODUCTS block Footer Title Placing the other modules useful for your store on other section of your pages. Before going further, I would like to emphasize two important points. They are: Always work on a copy of your default theme: If you have not copied the default theme file, I would advise that when you start your development work, you copy the default theme file so that you have a backup or a comparison to work with. We will be working on the copy of the default theme, as in some cases, we will still change a few lines of codes to modify the theme. This means that if you ever make a huge blunder, you will at least have the original to start with again. If the worst ever happens, you can always upload the original file again to overwrite your errors, but that will be a big waste of time. Keep a quick reference list of any modifications made to any file: It may sound a bit tedious, but you will find this advice useful to heed. There are a few ways of making modifications to your theme, sometimes through modification of your other files (which are not in the theme folder). You may copy the file and put it into the theme folder to make the changes, or it is also possible to merely modify them by overwriting the file in its location. Whichever way you chose, when you need to modify files which are not in your custom theme folder, you should make a quick note of what changes you have made and where have you made them. Why? Because when there is a new version of PrestaShop, you will need to upgrade your PrestaShop site, thus the modifications you have made will be lost. The modifications in the theme folders will remain even if you update the version of your PrestaShop site. By keeping a list of the modifications you've made, it will be much easier to track back to where to re-apply them after you have upgraded your PrestaShop installation. Never procrastinate on making this quick list because you will always find that it is a waste of time to find and trace those changes later; even just six months down the road. Copying the default theme file When you download PrestaShop, by default, you will have a copy of the PrestaShop theme folder. Go to the PrestaShop_1.3.1/themes/PrestaShop folder. Copy this entire folder and save it on your computer. You may rename the theme accordingly, for example, theme1. Compress this into a ZIP file. Upload the renamed folder into the themes directory on your hosting through your cPanel or FTP. You will now have two themes in your /themes folder which are PrestaShop and theme1. You can now log in to your PrestaShop Back Office | Preferences | Appearance and switch to your theme1 that you just installed and click on the Save button. On this page, you may also control what logo, favicon, and the navigation pipes you want to use throughout your website. Now, let's start with the modification of these theme elements to complete the look of your new theme. Logo A logo is an important element of a company's or store's image, and it can contribute to the brand's marketing success. Therefore, getting a good quality logo is fundamental for the business. Getting a unique and attractive logo design can be daunting, especially for those who are not born with a flair for design. However, fortunately, there are various resources that you can use to get ideas or even create a very professional looking logo that you can use in your new online store. Some online resources for logo designs can be found at: http://www.logomaker.com—This is an online resource that allows you to freely create a logo, but you have to pay to download your new creation, which basically uses their online inputs. Quite attractive and interesting looking logos can be found and designed here. http://cooltext.com—This one describes itself as A free graphics generator for web pages and anywhere else you need an impressive logo without a lot of design work. It allows you to choose the image you would like through a few simple steps. You only need to enter the words or company name using a form and you'll have your own custom image created on the fly. The logo you designed is downloadable for free. http://www.simwebsol.com/ImageTool/Default.aspx—This is a Web 2.0 logo generator. Free to use and download. It requires you to fill in a few fields and generates the image file quite easily. However, the background is limited to RGB flat choices and you only have 23 images that can be chosen from to insert. http://www.onlinelogomaker.com/ - A full featured free online logo design tool with a clean and easy interface and thousands of logo templates Another element, which is quite important here, is the favicon. The Favicon is the little icon representing the website you are visiting which gets displayed in the address bar of every browser. Usually, the favicon and the logo are the same thing, except for their sizes and the formats. They are not necessarily the same though. You may find some online resources that you can use to generate a favicon for the store. Make sure you have prepared the favicon icon before you try to replace the current favicon. If you are unsure of how to go about making a favicon, you may generate it online (using,http://www.favicon.cc/ or http://www.freefavicon.com/). Save the file on your hard drive and then upload it to your PrestaShop store. Uploading it is shown in the next section. Time for action—Replacing the default logo and favicon on your site The logo and the favicon can be replaced through Back Office | Preferences | Appearance, as shown in the following screenshot:     Browse the file you want to use from your computer. Upload the files and click on the Save button. You need to refresh your back office browser before you replace the logo and the new favicon.ico file. You also need to clean up your browser's cache and refresh the browser to see the favicon in the frontend of the website.     Upon saving and refreshing your browser, the updated images will be displayed. What just happened? In this simple exercise, you have just uploaded the logo that you had created, and PrestaShop has, by default, placed it in the correct directory in your new theme1 directory through the back office panel. If you did not choose the new theme, for example, theme1 in Preferences | Appearance under Themes, the logo you upload will go to the wrong directory. The Center Editorial Block The Center Editorial Block is where you see the main image at the center column, as we indicated previously in the front office. This is an important block, as this is where your visitors first arrive when they visit your store. It gives a first impression to your site visitor, and therefore, you need to consider what to include in it very carefully. Time for action—Modifying the Center Editorial block The Centre Editorial Block can be modified through Back Office | Modules | Tools | Home text editor. In this section, you can also edit the Centre Block image, which is referred to as Homepage's logo, and this title can be quite misleading as it may be confused with the actual logo. However, we have covered this matter in the previous article and did a mapping of each field here to the front office page of the store. You only need to upload the image you want to replace it with and continue with editing the Homepage logo link, which is the link for this image (Homepage's logo). You may just leave it set to your current website address if you want (for example, www.mydomainname.com). You can also leave it blank if you don't want the image to be a link. Furthermore, you will see Homepage logo subheading, which is the small letters you see on the default theme page that appear under the image. Let's replace the Homepage's logo image, Homepage logo link, and a new Homepage logo subheading: Click on the Update the editor button. Review your changes in your front office browser. You will need to refresh the page once to see the effect. It is possible to work with different image sizes, but the width of the image will "disturb" your column settings. If you are not going to make any unnecessary changes, then it is best to use images of the safe maximum width for the center column which is 530 pixels. If you exceed this width it will push your right column outside the standard browser view. Now let's have a look at what you have achieved so far. What just happened? You have modified your Center Editorial Block by inserting a new Homepage's logo image, Homepage logo link, and a new Homepage logo subheading. Top of pages block We will look at the header section of the page. The default layout comprises the following in the header section: Currency block (links to the available currencies used on the site). Languages block (links to the available language translation of the pages interface). Permanent link block: Contact (icon that links to the contact form page) Sitemap (icon that links to the sitemap page) Bookmark (icon that helps you bookmark a particular page on the site) Search block User links block: Your Account (icon that links to the login page or registration page). When logged in, it links to the account page that lists everything the customer can do with their account. It is only when the viewer is logged out that it links to the authentication page Cart (icon that links to the shopping cart summary page ) Welcome, Log in (links to the login page or registration page)     Time for action—Modifying the Top of pages To get these elements back on the pages, you will need to install and enable the relevant modules. These simple steps will need little modifications unless you want to add a new currency and a new language. Let's enable these modules through these simple steps: Currency block—go to Modules | scroll down to Blocks | Currency block. Languages block—go to Modules | scroll down to Blocks | Language block. Search block—go to Modules | scroll down to Blocks | Quick Search block. Permanent link block—go to Modules | scroll down to Blocks | Permanent links block. By default, these modules tend to appear on the pages in the order you installed and enabled them. The first one will appear the leftmost while the last one will be the rightmost. You can shift the arrangement by installing them according to what you want to appear on the leftmost or the rightmost sides. Notice that the Permanent link block is on the right as we enabled it last. There is an easier way to do this as well, which we will cover in the next section. You can modify this by working on the position of the modules within the Top of pages hooks. There are two similar hooks, which can be quite confusing, that is, the Top of pages and Header. The blocks are positioned or "transplanted" in a Top of pages hook and not Header of pages. The Welcome, Log in, Cart, and the User login links can be enabled through Back Office | Modules | Blocks | User info block. Upon installing and enabling the module, you will have the Welcome, Log in, Your Account, and Cart link displayed on your front office. By default, all those are automatically hooked to the Top of pages once they are enabled. If it is not, you can have it hooked through transplanting the module to the hook, as shown in the next screenshot. This can be done by following these simple steps: Go to Back Office | Modules | Position | Transplant a module.     Choose the Module you want to transplant from the drop-down menu. Choose the hook from Hook into, the one you want the Module to go into. Click on the Save button. The arrangement of the blocks can be done by moving them around within the hooks, which we will see next. Go to Modules | Positions. There you can arrange the position of the modules within the hooks by dragging each of them to the required position. As you can see, there are the two similar hooks which may be confusing, namely, the Header of pages and the Top of pages. Compare it with what you have at the front office in the next screenshot.   The Quick Search block does not appear despite it being hooked at the Header of pages. The other blocks which are hooked to the Top of pages are displayed in the front office. The same thing with the User info block; you only see the one which is hooked to the Top of pages and not the one in the Header of pages. The Top of pages hook is used to display a module at the top of the page. The Header of pages hook is used to put code in the <head> tag of the website. If you want to move a module or delete it from the top of the page, you should use the Top of pages hook, not the Header of pages hook. Modules that are in the Header of pages hook should not be removed, since they are required for the module to function correctly. For example, if you remove the Quick search block from the Header of pages hook, the search autocomplete will not work, since the code for it is missing. The resulting JavaScript error will also cause other problems on the website such as the Categories block not displaying any categories. To move the modules to the left or right, you need to move them up within the hook. The lower it is within the hook, the more to the right the module will appear, whereas the upper within the hook will be displayed on the left. For example, the Currency block is first in the list, and it is displayed on the left of the Top of pages section on the webpage. What just happened? You just learnt the differences between the hooks Top of pages and Header of pages in PrestaShop. You also get to modify the blocks you want to use on the top of the page and how to move them around within the hook.
Read more
  • 0
  • 0
  • 3828

article-image-nginx-http-server-base-module-directives
Packt
21 Jul 2010
7 min read
Save for later

Nginx HTTP Server: Base Module Directives

Packt
21 Jul 2010
7 min read
(For more resources on Nginx, see here.) We are particularly more interested in answering two questions—what are base modules and what directives are made available. What are base modules? The base modules offer directives that allow you to define parameters of the basic functionality of Nginx. They cannot be disabled at compile time; as a result, the directives and blocks they offer are always available. Three base modules are distinguished: Core module: Essential features and directives such as process management and security Events module: It lets you configure the inner mechanisms of the networking capabilities Configuration module: Enables the inclusion mechanism These modules offer a large range of directives; we will be detailing them individually with their syntaxes and default values. Nginx process architecture Before we start detailing the basic configuration directives, it's necessary to understand the process architecture, that is, how Nginx works behind the scenes. Although the application comes as a simple binary file, (apparently lightweight background process) the way it functions at runtime is rather intricate. At the very moment of starting Nginx, one unique process exists in memory—the Master Process. It is launched with the current user and group permissions—usually root/root if the service is launched at boot time by an init script. The master process itself does not process any client request; instead, it spawns processes that do—the Worker Processes, which are affected to a customizable user and group. From the configuration file, you are able to define the amount of worker processes, the maximum connections per worker process, and more. Core module directives Below is the list of directives made available by the core module. Most of these directives must be placed at the root of the configuration file and can only be used once. However, some of them are valid in multiple contexts. If that is the case, the list of valid contexts is mentioned below the directive name.root of the configuration file and can only be used once. Name and context Syntax and description daemon Accepted values: on or off Syntax: daemon on; Default value: on Enables or disables daemon mode. If you disable it, the program will not be started in the background; it will stay in the foreground when launched from the shell. debug_points Accepted values: stop or abort Syntax: debug_points stop; Default value: None. Activates debug points in Nginx. Use stop to interrupt the application when a debug point comes about in order to attach a debugger. Use abort to abort the debug point and create a core dump file. To disable this option, simply do not use the directive. env Syntax: env MY_VARIABLE; env MY_VARIABLE=my_value; Lets you (re)define environment variables. error_log Context: main, http, server, and location Syntax: error_log /file/path level; Default value: logs/error.log error. Where level is one of the following values: debug, info, notice, warn, error, and crit (from most to least detailed: debug provides frequent log entries, crit only reports critical errors). Enables error logging at different levels: Application, HTTP server, virtual host, and virtual host directory. By redirecting the log output to /dev/null, you can disable error logging. Use the following directive at the root of the configuration file: error_log /dev/null crit; lock_file Syntax: File path lock_file logs/nginx.lock; Default value: Defined at compile time Use a lock file for mutual exclusion. Disabled by default, unless you enabled it at compile time. log_not_found Context: main, http, server, and location Accepted values: on or off log_not_found on; Default value: on Enables or disables logging of 404 not found HTTP errors. If your logs get filled with 404 errors due to missing favicon.ico or robots.txt files, you might want to turn this off. master_process Accepted values: on or off master_process on; Default value: on If enabled, Nginx will start multiple processes: A main process (the master process) and worker processes. If disabled, Nginx works with a unique process. This directive should be used for testing purposes only as it disables the master process-clients thus cannot connect to your server. pid Syntax: File path pid logs/nginx.pid; Default value: Defined at compile time. Path of the pid file for the Nginx daemon. The default value can be configured at compile time. ssl_engine Syntax: Character string ssl_engine enginename; Default value: None Where enginename is the name of an available hardware SSL accelerator on your system. To check for available hardware SSL accelerators, run this command from the shell: openssl engine -t thread_stack_size Syntax: Numeric (size) thread_stack_size 1m; Default value: None Defines the size of thread stack; please refer to the worker_threads directive below timer_resolution Syntax: Numeric (time) timer_resolution 100ms; Default value: None Controls the interval between system calls to gettimeofday() to synchronize the internal clock. If this value is not specified, the clock is refreshed after each kernel event notification. user Syntax: user username groupname; user username; Default value: Defined at compile time. If still undefined, the user and group of the Nginx master process are used. Lets you define the user account and optionally the user group used for starting the Nginx worker processes. worker_threads Syntax: Numeric worker_threads 8; Default value: None Defines the amount of threads per worker process. Warning! Threads are disabled by default. The author stated that "the code is currently broken". worker_cpu_affinity Syntax: worker_cpu_affinity 1000 0100 0010 0001; worker_cpu_affinity 10 10 01 01; worker_cpu_affinity; Default value: None This directive works in conjunction with worker_processes. It lets you affect worker processes to CPU cores. There are as many series of digit blocks as worker processes; there are as many digits in a block as your CPU has cores. If you configure Nginx to use three worker processes, there are three blocks of digits. For a dual-core CPU, each block has two digits. worker_cpu_affinity 01 01 10; The first block (01) indicates that the first worker process should be affected to the second core. The second block (01) indicates that the second worker process should be affected to the second core. The third block (10) indicates that the third worker process should be affected to the first core. Note that affinity is only recommended for multi-core CPUs, not for processors with hyper-treading or similar technologies. worker_priority Syntax: Numeric worker_priority 0; Default value: 0 Defines the priority of the worker processes, from -20 (highest) to 19 (lowest). The default value is 0. Note that kernel processes run at priority level -5, so it's not recommended that you set the priority to -5 or less. worker_processes Syntax: Numeric worker_processes 4; Default value: 1 Defines the amount of worker processes. Nginx offers to separate the treatment of requests into multiple processes. The default value is 1, but it's recommended to increase this value if your CPU has more than one core. Besides, if a process gets blocked due to slow I/O operations, incoming requests can be delegated to the other worker processes. worker_rlimit_core Syntax: Numeric (size) worker_rlimit_core 100m; Default value: None Defines the size of core files per worker process. worker_rlimit_nofile Syntax: Numeric worker_rlimit_nofile 10000; Default value: None Defines the amount of files a worker process may use simultaneously. worker_rlimit_sigpending Syntax: Numeric worker_rlimit_sigpending 10000; Default value: None Defines the amount of signals that can be queued per user (user ID of the calling process). If the queue is full, signals are ignored past this limit. working_directory Syntax: Directory path working_directory /usr/local/nginx/; Default value: The prefi x switch defined at compile time. Working directory used for worker processes; only used to define the location of core files. The worker process user account (user directive) must have write permissions on this folder in order to be able to write core files.
Read more
  • 0
  • 0
  • 13653
Modal Close icon
Modal Close icon