Difference between pages "Zope Component Architecture" and "Talk:Download"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
m (Reverted edits by 103.22.193.154 (talk) to last revision by Whitewolf Fox)
 
Line 1: Line 1:
This page describes the Zope Component Architecture, or ZCA for short.
__NOTITLE__
= Download Funtoo Linux =


== ZCA: What is it? ==
Here are the steps you should follow to download Funtoo Linux stage3 tarball. If you need an install CD, please see [[Funtoo Linux Installation]] for Live Media recommendations. Funtoo Linux currently doesn't have its own LiveCD, but there are many that you can use for installation.


The Zope Component Architecture is a Framework that arose out of Zope 3 development, and is now integrated into Zope 2. It is used by various software projects, and doesn't even require Zope to run. You can use it natively with Python. It's part of Zope, but it's not Zope.
== First, Pick a Mirror... ==


=== Why Should I Use It? ===
Funtoo Linux can be downloaded at the following locations:


You shouldn't. Well, I mean, don't use it unless you see the value in it, or if you are using a software project that uses it already. Due to the fact that it is a framework, it does impose a paradigm on how you develop Python code and you need to determine if that paradigm works for your particular situation, or if it doesn't.
* Main US mirror: [http://ftp.osuosl.org/pub/funtoo/ The Oregon State University Open Source Lab]
* Main EU mirror: [http://ftp.heanet.ie/mirrors/funtoo/ HEAnet]


=== The Paradigm ===
== Now... pick a build ==


In one phrase, the paradigm implemented by the ZCA framework is that of a "component architecture", which in itself may not mean anything to you, but it is easy to understand.  
'''Now you'll first need to pick a ''build'' of Funtoo Linux to install.''' Builds are like different versions of Funtoo Linux. Our '''funtoo-current''' build is the most up-to-date and recommended build. We also offer '''funtoo-stable'''. Both current and stable share the use the same Portage tree (package repository), but newer packages are unmasked (made available for install) in '''funtoo-current'''.


If you are reading this, you have probably developed some Python software. Now imagine if you had to lead a team that is developing a complex Python software application. This type of project presents new challenges that you may not experience as an individual developer.  
There is also a '''funtoo-experimental''', which contains our experimental development work. As you might guess, funtoo-experimental is for developers and testers only, and it has its own experimental Portage tree that is separate from the others.


For one, different members of the team have different skill sets. You also want the team to be able to work in parallel rather than have some members of the team sit idle waiting for parts they depend upon to be completed. Ideally, you would want to split the application into logical parts and then clearly define who is doing what part of the software and what each team is delivering. But when the software is complete, it needs to work together as an integrated unit.
If you don't know which one to choose, pick '''funtoo-current'''.


Clearly, you will need to think about the software architecture. But it can also be helpful to have a framework your team can use that helps them to split the application into logical parts, develop these parts in parallel, and then allow these various parts to interact once they are done. This is what a component architecture is typically used for. It supports this style of development.
Picked one? Great! Open a mirror in a new window, and select the appropriate build directory from the list.


=== Interfaces ===
<pre>
funtoo-current ->
</pre>


You decide to split your team into smaller groups, and each group will tackle one part of the software. One group's code will need to interact with another group's code, but ''many parts depend upon other parts that haven't been written yet''. To solve this chicken-and-egg problem, the groups need to define ''interfaces'' for how others will be able to utilize their code, even before it is written. These interfaces are the interaction points for one group to utilize software that other groups write.  
== Next... pick an arch ==


Now we have added an additional layer of complexity to the software development project -- the effort of defining these interfaces. But we expect the investment to reap major rewards in mere days as this model of development will allow each group to actively develop their part of the application without waiting on another group to complete theirs first. While this could be done without ZCA, essentially all of ZCA is designed to help facilitate this style of development.
'''Next, it's time to pick an ''architecture'''''. If you have a modern 64-bit PC-compatible desktop or server, you generally want '''x86-64bit'''.  If you have an older 32-bit PC-compatible desktop or server, you'll want to use '''x86-32bit'''. Also an option for 64-bit x86 systems.


Now that you understand this, you will have a better appreciation for why ZCA is designed the way it is. It is trying to provide a framework for building larger projects that cannot be handled by a single developer. It does add some complexity to your project. This is intentional. You should only use ZCA if you expect that the additional complexity will be more than offset by improved productivity, maintainability and software quality that can arise from a component-based architecture. So, is it right for you? There is no one answer to this. The right answer will depend on the complexity of the project, your development team, and other factors.
We also bundle virtualization directories alongside the architecture directories, so if you want to install an [[OpenVZ]] container of Funtoo Linux, select '''openvz''', then pick the correct ''architecture'' within. Likewise, if you're looking for a [[VagrantUp|Vagrant]] run image of Funtoo Linux, look in the '''vagrant''' directory.


At least now you know what ZCA is designed for, so you will be able to evaluate it fairly :)
If you are installing Funtoo Linux on a Sparc64 system, choose '''sparc-64bit'''.


Martin Aspeli has written [http://www.martinaspeli.net/articles/of-babies-and-bathwater-or-why-i-love-the-zope-component-architecture a defense of ZCA].
<pre>
funtoo-current -> x86-64bit
</pre>


== The Parts of ZCA ==
== Now... select a sub-arch ==


This section describes the "components" of ZCA itself. One of the most complicated things about ZCA is the new terminology that it uses for its various parts. Once you understand this terminology, ZCA is a lot more approachable. Also see [http://wiki.zope.org/zope3/ComponentArchitectureOverview]
Now, you'll need to pick a ''sub-architecture'' of Funtoo Linux that suits your needs. A sub-architecture is a build of Funtoo Linux that is optimized for your particular CPU.  


; Components: A component is Python-based code, usually a class, that implements an ''Interface'' (defined below.)
If you are building a Linux-based appliance or grabbing an image for mass-deployment, you might want to choose a generic sub-architecture that will be compatible with a wide range of processors. Otherwise, choose the most optimized sub-architecture that your processor supports.
;Interfaces: Interfaces are special Python classes that are declared for the sole purpose of describing functionality implemented by another class or module. They are registered with a component registry, and others can query the registry for components that implement a particular interface. Objects can advertise that they implement a particular interface. From a code perspective, interfaces are the heart of ZCA.
; Services: A service is generally a Python object that deals with components, and provides some functionality to your application. Think of components as "things", and services as parts of your code that take these "things" and perform useful actions with them.
;Component Registry: The Component Registry, also called a ''Site Manager'', is a directory of components, and acts as the central organizational hub of ZCA. It is a ''service'' (as defined above.) You register components with the component registry, and then others can query the registry for components that they need. There is a ''global'' component registry that is automatically created for you, and you can use the ZODB as a ''local'' component registry.
;Global Component Registry: The Global Component Registry a service that is automatically created when your ZCA-based application starts, and is populated with components based on your application's ZCML configuration files. Any part of your application can access the Global Component Registry. When your application shuts down, the Global Component Registry no longer exists. It will be re-initialized from ZCML when your application is started again.
;Local Components: Local components are components that are not instantiated as part of the Global Component Registry. They are typically stored in the traditional Zope storage infrastructure, the ZODB, which also means that they are ''persistent'', in that they will survive multiple application starts/stops. Because they exist in the ZODB, Zope will use ''acquisition'' (a traditional Zope way of finding things in the ZODB) to retrieve local components when your application queries the ZODB.
;ZCML: Pronounced "Z-camel", ZCML is an XML-based configuration file syntax that is used to register components with the global component registry. It is useful in that it provides a mechanism to add new components using configuration files rather than touching source code. It also provides a mechanism to easily extend ZCA code by overriding existing components with new implementations -- all without touching existing Python source code.
;Adapters: Adapters are Python classes that allow new interfaces to be used with existing objects. More specifically, an Adapter class will contain an <tt>adapts()</tt> call in the class body that specifies that it ''adapts'' an interface, which means that you can pass any object that implements that interface to the adapter class' <tt>__init__()</tt> method, such as <tt>a = myAdapter(myobject)</tt>. <tt>MyAdapter</tt> now takes care of acting as a front-end for <tt>myobject</tt> so that any interfaces implemented by <tt>myAdapter</tt> will interact properly with <tt>myobject</tt>. In a sense, the adapter "eats" the adapted object.
;Factories: A factory is something (technically, a ''Utility'', see below) that creates components and objects. It is like a higher-level version of a constructor. A Factory must be ''callable'' and implement the <tt>IFactory</tt> interface. Factories offer a convenient means to access component constructors via a component registry, rather than connecting to the constructor directly in Python code. It's important to note that ''ZCML creates factories for you automatically when you register components. This means that in many cases, you do not need to deal directly with Factory creation.''
;Utilities: A utility is a Python object that you want to add to the component registry. It could be any type of Python object that another part of your application may need. A utility must implement at least one interface. [http://bluebream.zope.org/doc/1.0/howto/localsitemanager.html#how-does-it-usually-look-like The Zope Documentation] has some guidance on when it's appropriate to create a utility.
;Multi-Adapters: Multi-adapters are adapters that have the ability to adapt one than more type of object.
;Subscription Adapters: Adapters can be registered as subscription adapters, and then ''all'' adapters that adapt a particular object can be retrieved by calling the <tt>zope.component.subscribers()</tt> function. This is useful when doing things like validation, where you want to get back a bunch of adapters that apply to a specific object. Subscription adapters can return a value.
;Handlers: Handlers are like subscription adapters, but they do not return a value to the caller. They go off, "handle" something, and then return.
;Overrides: If you register multiple components with the same arguments, the last component registered will replace any previously-registered components. This behavior is used to replace existing components with new ones that may implement new functionality.
;Invariants: Invariants are functions that you attach to your interfaces that throw exceptions when certain conditions aren't met. Invariants are invoked by calling the interface's <tt>validateInvariants</tt> method, passing the object to be validated as an argument.


== ZCML ==
Note that we offer the greatest number of choices for '''funtoo-current'''. Other builds will have a more limited number of sub-arches available.


The official specification for ZCML is viewable in the [http://apidoc.zope.org/++apidoc++/ Zope 3 APIDoc site], although this may not accurately reflect the API in Zope 2.13. In terms of explanatory, conceptual documentation, there does not seem to be anything good available, and this section will attempt to fill that gap.
=== x86-64bit ===


For now, read the [http://codespeak.net/z3/five/manual.html Five Manual] and work through the <tt>[http://svn.zope.org/z3/Five/trunk/demo/?rev=46891#dirlist demos]</tt> directory.
* '''corei7''': Intel Core i3, Core i5 and Core i7 desktop processors or higher. Xeon 5500, 5600 and 7500 series server processors or higher. (Nehalem, Sandy Bridge)
* '''core2_64''': Intel Core 2 series or higher, which include the Core 2 Solo, Duo, Quad and Extreme. Also suitable for Nehalem.
* '''atom_64''': Intel Atom optimized. Compatible with Core 2 series.
* '''amd64-k8''': AMD Opteron or Athlon 64 processors, or higher
* '''amd64-k10''': AMD Phenom, Phenom II and compatible, or higher
* '''generic_64''' : Generic 64-bit Intel/AMD processor
 
=== x86-32bit ===
 
*'''core2_32''': Intel Core 2 series or compatible, which include the Core 2 Solo, Duo, Quad and Extreme. Also suitable for Nehalem.
*'''atom_32''': Intel Atom optimized. Compatible with Core 2 series.
*'''amd64-k8_32: AMD Opteron or Athlon 64 processors, or higher.
*'''athlon-xp''': Athlon XP or Opteron/Athlon 64.
*'''i686''': Generic P6-class system
*'''i486''': Intel 80486+ system
 
You should now grab the most recent stage3 for the sub-architecture that you've chosen:


<pre>
<pre>
<?xml version="1.0" encoding="utf-8"?>
funtoo-current -> x86-64bit -> corei7 -> stage3-latest.tar.xz
<configure
        xmlns="http://namespaces.zope.org/zope"
        xmlns:browser="http://namespaces.zope.org/browser"
        xmlns:five="http://namespaces.zope.org/five">
</configure>
</pre>
</pre>
Check out this excellent [http://plone.org/products/dexterity/documentation/manual/five.grok Zope Component Architecture basics with five.grok] tutorial from Martin Aspeli.
[[Category:Zope]]
[[Category:Developer]]
[[Category:Featured]]

Latest revision as of 11:46, November 5, 2012

Download Funtoo Linux

Here are the steps you should follow to download Funtoo Linux stage3 tarball. If you need an install CD, please see Funtoo Linux Installation for Live Media recommendations. Funtoo Linux currently doesn't have its own LiveCD, but there are many that you can use for installation.

First, Pick a Mirror...

Funtoo Linux can be downloaded at the following locations:

Now... pick a build

Now you'll first need to pick a build of Funtoo Linux to install. Builds are like different versions of Funtoo Linux. Our funtoo-current build is the most up-to-date and recommended build. We also offer funtoo-stable. Both current and stable share the use the same Portage tree (package repository), but newer packages are unmasked (made available for install) in funtoo-current.

There is also a funtoo-experimental, which contains our experimental development work. As you might guess, funtoo-experimental is for developers and testers only, and it has its own experimental Portage tree that is separate from the others.

If you don't know which one to choose, pick funtoo-current.

Picked one? Great! Open a mirror in a new window, and select the appropriate build directory from the list.

funtoo-current ->

Next... pick an arch

Next, it's time to pick an architecture. If you have a modern 64-bit PC-compatible desktop or server, you generally want x86-64bit. If you have an older 32-bit PC-compatible desktop or server, you'll want to use x86-32bit. Also an option for 64-bit x86 systems.

We also bundle virtualization directories alongside the architecture directories, so if you want to install an OpenVZ container of Funtoo Linux, select openvz, then pick the correct architecture within. Likewise, if you're looking for a Vagrant run image of Funtoo Linux, look in the vagrant directory.

If you are installing Funtoo Linux on a Sparc64 system, choose sparc-64bit.

funtoo-current -> x86-64bit

Now... select a sub-arch

Now, you'll need to pick a sub-architecture of Funtoo Linux that suits your needs. A sub-architecture is a build of Funtoo Linux that is optimized for your particular CPU.

If you are building a Linux-based appliance or grabbing an image for mass-deployment, you might want to choose a generic sub-architecture that will be compatible with a wide range of processors. Otherwise, choose the most optimized sub-architecture that your processor supports.

Note that we offer the greatest number of choices for funtoo-current. Other builds will have a more limited number of sub-arches available.

x86-64bit

  • corei7: Intel Core i3, Core i5 and Core i7 desktop processors or higher. Xeon 5500, 5600 and 7500 series server processors or higher. (Nehalem, Sandy Bridge)
  • core2_64: Intel Core 2 series or higher, which include the Core 2 Solo, Duo, Quad and Extreme. Also suitable for Nehalem.
  • atom_64: Intel Atom optimized. Compatible with Core 2 series.
  • amd64-k8: AMD Opteron or Athlon 64 processors, or higher
  • amd64-k10: AMD Phenom, Phenom II and compatible, or higher
  • generic_64 : Generic 64-bit Intel/AMD processor

x86-32bit

  • core2_32: Intel Core 2 series or compatible, which include the Core 2 Solo, Duo, Quad and Extreme. Also suitable for Nehalem.
  • atom_32: Intel Atom optimized. Compatible with Core 2 series.
  • amd64-k8_32: AMD Opteron or Athlon 64 processors, or higher.
  • athlon-xp: Athlon XP or Opteron/Athlon 64.
  • i686: Generic P6-class system
  • i486: Intel 80486+ system

You should now grab the most recent stage3 for the sub-architecture that you've chosen:

funtoo-current -> x86-64bit -> corei7 -> stage3-latest.tar.xz