forked from plone/training
-
Notifications
You must be signed in to change notification settings - Fork 0
/
ablauf_old.txt
2462 lines (1657 loc) · 92.7 KB
/
ablauf_old.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
========
TRAINING
========
**Day 1**
1. Introduction (15 Min)
2. Installation & Setup (60 Min) (Philip)
3. The features of Plone (45min) (Philip)
4. Simple Customisations (45min) (Philip)
5. Extending Plone with Addons (80min) (Patrick & Philip)
5.1 Theming
6. buildout I (30min) (Patrick)
7. Plone-IDE's (15min) (Patrick)
8. Creating your own eggs to customize Plone (15min) (Patrick)
9. Creating a new content-type "Talk" with Dexterity (45min) (Philip)
10. Views I (60min) (Patrick und Patrick)
**Day 2**
11. Views II: A default view for "talk" (45min) (Patrick)
12. Views III Talk list (45min) (Philip)
13. Extending CTs with Behaviors (30min) (Patrick)
14. Adding a Viewlet (30min) (Philip)
15. Deploying your code (15min) (Patrick)
16. Buildout II deploying your site (60min) (Patrick)
1. Introduction (10 Minutes)
============================
Who are we?
-----------
We introduce each other
* Patrick Gerken, do3cc, [email protected]
* Philip Bauer, pbauer, [email protected]
* Starzel (http://www.starzel.de)
* Munich User Group
Who are you?
------------
Please introduce yourselves:
* name, company, country...
* Your plone experience
* Your web-development experience
* What is your motivation to go to tutorial
* What are your expectation for tutorial
* Do you know the html of the output of this?::
<div class="hiddenStructure"
tal:repeat="num python:range(1, 10, 5)"
tal:content="structure num"
tal:omit-tag="">
This is some weird sh*t!
</div>
* Do you know what the following would return?::
[(i.Title, i.getURL()) for i in context.getFolderContents()]
* What is your favorite editor?
What will we do?
----------------
Technologies and tools we use today
* git
* github
* virtualbox
* vagrant
* ubuntu linux
* TTW (a lot!)
* buildout
* TAL
* METAL
* zcml
* grok
* python
* dexterity
* viewlets
* jquery
What we will not do?
--------------------
We will not cover the following:
* archetypes
* portlets
* genericsetup
* z3c.form
* caching
* hosting
* Diazo
* Theming
* tests
* deco and tiles
* image-scales
* i18n and locales
What to expect
--------------
You won't be a plone-programmer after these 2 days. You will know some of the more powerfull features of Plone and should be able to construct a website on your own using these tools. You should also be able to find out where to look for instructions to do tasks we did not cover. You will know most of the core-technologies involved in plone-programming.
If you want to become a plone-developer or plone-integrator you should definitvely read Martins book and re-read it again. Most importantly you should practice your skills and not stop here but go forward!
If you want to stay on the ttw-side of things you could read "Practical Plone" (http://www.packtpub.com/practical-plone-3-beginners-guide-to-building-powerful-websites/book).
Other
-----
* Breaks
* Food, Restrooms
* Questions
* WIFI: fairtraderocks
2. Installation & Setup (60 Min) (Philip)
=========================================
Hosting your own site
---------------------
If you want to host a Plone-website yourself then running it on your Laptop may not be the smartest option. We will cover some options for hosting tomorrow. One option is http://ploud.com whre you can host one real Plone-Site for free.
Options:
* Ploud.net
* Webfaction
* gocept
* Starzel
* AWS
* Rackspace
Brief introduction of several installation-options
--------------------------------------------------
Plone 4.2 requires a working Python 2.7 and several other system-tools that not every OS provides. Therefore the installation of Plone is differen on every system (
* MacPorts / homebrew
* python-buildout
* PyWin32
* Linux-packages
* pre-installed Pythons
MacOS 10.8 and Ubuntu 12.4 come with a working default Python 2.7 built in. These are the lucky ones. But to run a older Plone-version you need Python 2.4 and that's not always easy to install.
To find out how to install Plone on your machine read http://plone.org/documentation/manual/installing-plone
Everyone usually uses his primary system to develop Plone. I use MacOS and therefore I use the python-buildout (https://github.com/collective/buildout.python) to compile all neccessary version of python and homebrew (http://mxcl.github.com/homebrew/) for some linux-tools. Patrick uses ubuntu. Our friend Stefan always uses the unified installer's python. Alan Runyan (one of Plone's founders) uses Windows and i have no idea how he can live with that.
* unified installers for all 'nix (including MacOS)
* one-click installers for Windows and Mac
* very old package for debian (don't use)
* use some your python and create your own buildout
Vagrant and Virtualbox
----------------------
To not waste too much time with installing and debugging the differences between systems we use a virtual machine (ubuntu 12.4) to run Plone during the training. We install virtualbox and vagrant a wrapper that manages virtual machines.
Vagrant is a wrapper for Oracle’s VirtualBox to create and manage virtual environments.
Installation
------------
*All these steps are done by vagrant/puppet.*
We'll first use the unified installer and the default Plone-configuration (called buildout) that comes with it. Later we'll create our own buildout and extend it as we wish.
The first installation is in fact done by Puppet, a tool to automatically manage servers (real and virtual). We won't get into it Puppet since it's not that widely used. This is what we bascally do if we did it by hand:
First we install some packages::
$ sudo aptitude update --quiet --assume-yes
$ sudo apt-get install python-dev python-virtualenv libjpeg62-dev libxslt1-dev git-core subversion zlib1g-dev libbz2-dev wget curl elinks gettext
Then we create a virtual python environement using virtualenv. This is alway a good practice since that way we get a clean copy of our system-pythonm we can't break it by installing stuff that might collide with other stuff::
$ virtualenv --no-site-packages py27
Then we download, unpack and install the unified installer of Plone::
$ mkdir training
$ mkdir tmp
$ cd tmp
$ wget https://launchpad.net/plone/4.2/4.2.1/+download/Plone-4.2.1-UnifiedInstaller.tgz
$ tar xzf Plone-4.2.1-UnifiedInstaller.tgz
$ cd Plone-4.2.1-UnifiedInstaller
$ ./install.sh standalone --with-python=/home/vagrant/py27/bin/python --password=admin --instance=zinstance --target=/home/vagrant/training
The unified installer is an amazing tool that compiles it's own python, brings with it all the python-eggs we need and puts them in a buildout-cache. It then creates a buildout and makes Plone ready to run.
We'll use this Plone, that is found in /home/vagrant/training/zinstance on the virtual machine.
Later we'll leave the unified installer behind and build our own little buildout. Buildout will be explained later in depth.
Customising the buildout (Patrick)
----------------------------------
TODO: (enter "admin" as password?)
Now, lets run buildout and wait a bit...
Buildout will create a start script for us. The start script accepts some parameters, the first is the command.
Starting Plone (Patrick)
------------------------
We control Plone with a small script called "instance"
``$ ./bin/instance fg``
this starts Plone and we can see what it's doing
It offers the following options::
./bin/instance fg
./bin/instance start
./bin/instance fstop
./bin/instance debug -O Plone
Depending on your computer, it will take up to a minute until zope will tell you that its ready to serve requests.
A Zope Standard installation always listens on port 8080, so lets have a look at our Zope Site by visiting http://localhost:8080
As you can see, there is no Plone yet!
We have a running zope with a database but no content. But luckily there is that button to create a zope site.
Click on that button. Use "Plone" as the site id.
The anatomy of Plone introduction (Patrick)
-------------------------------------------
Systemarchitektur erklären (5 Minuten)
* Zope
* Scripts in the database
* Acqusition to simulate class and stuff, persistency.
* CMF
* Plone
* Erweiterungen
Now, lets clear up a bit of mumbo jumbo.
I talk about Zope, sometimes about Plone. Whats the difference about that?
Zope is an application server. Before zope, there usually was an apache server that would call a python script, and send the request via stdout or something. The script would then just print some stuff and this was the html.
Jim Fulton thought, that this is pretty stupid. So he wrote some code to handle requests. He believed that site content is object oriented and that the url should somehow point directy into the object hierarchy, so he wrote an object oriented database, called ZODB. Then there where transactions, so that it became a real database and after a while, python scripts that could be edited through the web, followed. One lost puzzle is important, Acquisition.
Acquisition was kind of magic. Imagine a world, where there is no file system, and there are no imports. That is the vision of zope. Now if you have a folder food, and in there is a folder fruits, and in there is a page apple, and there are many many different pages on different levels in hierarchy, how would you implement some kind of functionality like displaying an e-mail adress that is defined centraly? The Answer is acquisition. In my View, I would maybe call context.getEmail(). Context stands for the object on which I currently am in the ZODB. Now there is no script getEmail() in here, but thanks to acquisition, python looks for the attribute a level higher, and another level and so on. This is the way to go for writing whole applications through the web and in a structured manner.
Basically this is Zope.
When I open http://localhost:8080/Plone/manage, I see the Zope Management Interface, a view into my object oriented database.
After many successfully created websites based on zope, a number of recurring requirements emerged, and the CMF, the Content Management Framework was written.
Most objects you see in the ZMI are part of the CMF somehow.
The people behind CMF did not see CMF as a CMS. They created a CMS Site which was usable out of the box, but made it deliberately ugly, because you have to customize it anyway.
This is one way to do it. Plone Founders Alexander Limi and Alan Runyan thought differently, and created a CMS that was usable and beautiful out of the box. Plone.
Well, what do you think was a more successful way to go on?
(Hint: Last german zope conference (2010): 80 ppl (There is no international zope conf), First german plone conf(2012): 150ppl)
In practice, there is much much less in Zope world going on than in the Plone World. That means, that the question, what is part of CMF and what not, is a bit diluted. CMFEditions is not part of CMF, btw.
So the important parts are this:
We run Zope, the application server. Our Main application is Plone.
3. The features of Plone (45min) (Philip)
=========================================
* Users
* Walktrough of the UI
* Content-Types
* Pages and Folders
* Content-Management
* Collections
* Content Rules, History,
* Working Copys
* User-Management, Roles und Groups
* Workflows
* Placeful Workflows
Users
-----
Now let us create our first user within Plone. So far we used the admin-user (admin:admin) configured in the buildout. He is often called "zope-root". This user is not managed in Plone but only in by Zope. Therefore he's missing some features like email and fullname and he won't be able to some of plone's features. But he has all possible permissions.
You can add zope-users also via the terminal by entering::
$ ./bin/instance adduser rescueuser secretpassword
This way you can access databases you get from customers wehere you have no Plone-user.
Now click on the name "admin" in the top right corner and then on "Site setup". This is Plone's control panel. You can access it by browsing to http://localhost:8080/plone-control_panel
Click on "Users and Groups" and add a user. We use pbauer or pgerken as usernames. If you'd have configured a mail-server, Plone can send you a mail with a link to a form where you can chose a password. We set a password here because we didn't configure a smtp-server.
Make this user with your name an admin.
Create another user called testuser. Make him a normal user.
*Firefox --noremote ist ein Weg, um mit unterschiedlichen Nutzern gleichzeitig auf einer Webseite angemeldet zu sein*
Now let's see the site in 3 different browser logged-in in three different roles:
* as anonymous
* as editor
* as admin
Walktrough of the UI
--------------------
Let's see what is there...
* portal-top: logo, search, global-navigation (viewlets)
* portal-columns: a container
* portal-column-one: portlets
* portal-column-content: the content and the editor
* portal-column-two: portlets
* portal-footer: viewlets
These are also the css-classes of the respective div's. Get used to them if you want to do theming you'll need them.
Content-Types
-------------
Edit a page:
* Edit frontpage
* Title: "Plone Conference 2012, Arnhem"
* Description "Tutorial"
* Text "..."
Create a site-structure:
* Add folder "The Event" and in that ...
* Folder "Talks"
* Folder "Training"
* Folder "Sprint"
* In /news: Add News Item "conf website online!" with image
* In /news: Add News Item "submit your talks!"
* In /events: Add Event "Deadline for talk-submission" Date: 10.10.2012
* Add Folder "Register"
* Delete "members"
* Add Folder "Intranet"
Explain default content-types:
* Document
* News Item
* Event
* File
* Image
* Link
* Folder
* Collection
Folders
-------
* Go to 'the-event'
* explain title/id/url
* explain /folder_contents
* change order
* bulk-actions
* dropdown "display"
* default_pages
* Add a page to 'the-event': "The Event" and make it the default-page
Collections
-----------
* add a new collection: all content that has pending as wf_state.
* explain http://localhost:8080/Plone/events/aggregator/edit
* old vs. new collections (in 4.2. new collections are the default)
* mention collection-portets
Content Rules
-------------
* Create new rule "a new talk is in town"!
* New content in folder "Talks" -> Send Mail to reviewers.
History
-------
explain
Manage members and groups
-------------------------
* add/edit/delete Users
* roles
* groups
* Add group: orga
* add group: speaker
Workflows
---------
* screenshots?
* Show plone.app.workflowmanager
Working copy
------------
* enable addon
* explain
Placeful workflows
------------------
* enable addon
* explain
4. Simple Customisations (45min) (Philip)
=========================================
* Configuring Plone with /plone_control_panel
* Portlets
* Viewlets
* ZMI (plus intro to ZMI)
* portal_actions
Configuring Plone with /plone_control_panel
-------------------------------------------
Click name
Click "Site Setup"
1. Add-ons (later...)
2. Calendar
3. Configuration Registry
4. Content Rules (we know this already)
5. Discussion
6. Editing
7. Errors
8. HTML Filtering
9. Image Handling
10. Language
11. Mail
12. Maintenance
13. Markup
14. Navigation
15. Search
16. Security
17. Site
18. Themes
19. TinyMCE Visual Editor
20. Types
21. Users and Groups
22. Workflow Manager
23. Zope Management Interface (here be dragons)
Portlets
---------
explain portlets:
* @@manage-portlets
* UI fit for smart content-editors
* explain various types
* inheritance
* managing them
* ordering/weighting
* will be replaced by tiles?
Example:
* right: add static portlet "Sponsors".
Viewlets
--------
* @@manage-viewlets
* no UI - not for content-editors
* not locally addable, no configurable inheritance
* will be replaced by tiles?
* the code is much simpler (we'll create one tomorrow)
* viewlet-manager
* ttw-reordering only within the same viewlet-manager
* the programer descides when it's where and what it shows
Portlets save Data, Viewlets usually don't. Viewlets are often used for UI-stuff.
example: hide collophon
ZMI
---
Köln ist eine Stadt die über 1000 Jahre alt ist. Es gibt heutzutage aber keine Infrastruktur mehr die von den Römern geschaffen und von uns noch genutzt werden. Zope ist der Unterbau von Plone und der Altersunterschied zwischen Zope und Plone ist wesentlich geringer als zwischen Köln und Colonia, aber als Kölner muss man Köln ja auch mal erwähnen. Aber in einem Aspekt hinkt der Vergleich nicht, wenn man im modernen Köln Mist baut, wird man nicht den Löwen zum Frass vorgeworfen, im alten Zope/Colonia kann das passieren. Es gibt Dinge die man dort nicht tun sollte, weil Plone dadurch kaputt geht. Wenn man doch etwas in Zope machen muss, ist das normalerweise gut auf Plone.org dokumentiert. Lustige Geschichten, wir sich andere (also wir noch nie!) In den Fuss geschossen haben erzählen wir gerne beim Social Event. Daher werden wir erst später was zu Zope und dem Zope Management Interface, ZMI erzählen.
Actions
-------
Go into the ZMI (explain /manage)
Mostly links but really flexible links :-)
Manchmal soll ein Link aber mehr Eigenschaften haben, Links sollten eine Beschreibung haben können, und Bedingungen, zum Beispiel der Kontext oder ein benötigtes Recht. Ausserdem sollte das ganze Konfigurierbar sein, ohne das wir dazu HTML anpassen müssen. Dazu gibt es in Plone schon seit dem alten Rom das Konzept der Portal Actions. Dort werden kleine Objekte angelegt mit all diesen Eigenschaften, und im HTML werden diese Objekte, die Actions heissen abgefragt und entsprechend Texte geschrieben, Icons angezeigt und dergleichen.
Ein Beispiel für diese Links sind die grauen Reiter oben. Wir nehmen nun den Link auf die Startseite raus, die Besucher können auch auf das Logo klicken.
Kräftig durchatmen, wir sind nun in den Katakomben dem ZMI, bitte nichts berühren, sonst stürzt alles ein ;-)
go to portal_actions -> portal_tabs
Where is my navigation?
The navigation shows content-objects, which are in Plone's root. Plus all actions in portal_tabs
explain & edit index_html
Derzeit gibt es nur diese eine, die wir uns vor dem Löschen ganz kurz anschauen, bitte drauf klicken
Add a link to the imprint to the bottom:
go to site_actions (we know that because we chacked in manage-viewlets) > add a CMF Actions 'imprint' and point it at string:${globals_view/navigationRootUrl}/imprint
Explain permissions, condition,
If time explain:
* user > undo (cool!)
* user > login/logout
5. Extending Plone with Addons (80min) (Patrick)
================================================
* Introduction (10min)
* Installing Addons (5min) (+ infos on uninstalling)
* PloneFormGen (15min)
* Internationalisation with LinguaPlone (20min) (Philip)
* Add bling with PloneTrueGallery (10min) (Patrick)
* Customizing the design with plone.app.themeeditor (20min) (Philip)
* export egg
Zope is extensible, as is Plone.
Nowadays everybody installs eggs. Eggs are a bunch of python files, together with other needed files like page templates and the like and a bit of Metadata.
Eggs are a much much younger than Zope. Zope needed something like eggs before there were eggs, and the Zope Developers wrote their own system, which we still see at some parts. But more and more functionality is pushed into the eggs alone.
Now, how can one extend Plone? A number of extensions create new things that can just be added to plone, like content types. Other things change functionality, like how the search page works or how the site looks like overall.
There are three different ways to extend Plone:
skin folders. Remember acquisition? Skin Folders are an extension of acquistion. I have a folder portal_skins. This contains a bunch of folders. I have a property on the portal_skins, that defines in which order attributes or objects should be looked for in the skin folder. If in some folder there is a python script called getEmail, and I want it to send obfuscated emails, my addon would add another folder to the portal_skins, and would add itself to the ordering so that the new folder would be looked for before the original folder. This way I can override behavior.
The next thing is GenericSetup. As the name clearly implies, GenericSetup is part of CMF. It is badly documented.
GenericSetup lets you define persistent configuration in xml files. Genericsetup parses the xml files and updates the persistent configuration accordingly. This is a step you have to run on your own!
Typically you use GenericSetup to modify workflows or add new content type definitions.
The last thing is ZCML. A bit of history again. When Zope started, Object oriented Design was the totally awesome technology. Zope objects have more than 10 Base Classes. After a while, XML and Components became a hype (J2EE anyone). So the Zope developers wanted a completely new Zope, component based. It is easier to swap out components than always subclass. The whole thing was named Zope 3, did not gain traction, was renamed to Bluebream and died off. But the component architecture itself was quite successfull and was extracted into the Zope Toolkit, which is integrated in Zope and heavily used in Plone. This is what you want to use.
For customizing, you can create utilities, adapters and views(MultiAdapters).
What is the absolute simplest way to extend functionality?
Monkey Patching. In code, during load time I import some code and replace it with my own code.
If one can have multiple implementations for something, I could make a global dictionary where everybody just adds its functionality during boot up. This does not scale. Multiple plugins might overwrite each other. Here comes the Zope Component Architecture and ZCML. With ZCML I declare my utilities, adapters and browser views in ZCML, which is a XML dialect. During start up, Zope reads all these ZCML statements, validates that there are not two things trying to register the same things and only then registers everything. This is a good thing. ZCML is btw. only ONE way to declare your configuration, another technology is Grok, where some python magic allows you to decorate your code directly with some magic to make it an adapter. And these two ways of configuring can be mixed.
Many ppl hate ZCML and avoid Zope because of it. I just find it cumbersome but even for me as a developer, it offers a nice advantage. Because of zcml, whenever I need to find out, where something has been implemented, the zcml files are like a phone book for me.
Installation
------------
Installation is a two step process. First, we must make our code available to Zope. This means, it must be importable. This is handled by Buildout.
ssh to your vagrant, and modify the buildout.cfg files in training/zinstance.
PloneFormGen, Products.LinguaPlone and Products.PloneTrueGallery, collective.plonetruegallery
DO THIS NOW
RESTART
After that the code is available, the ZCML gets loaded, so browser views, adapters and so on are available, but Plone is not configured to use this.
For this, you have to install the extension in your Plone Site.
Go to the Products Panel.
This is what happens now: The GenericSetup profile of the product gets loaded. This does things like configuring new actions, registering new
content types or adding browser views.
PTG
---
I LOVE PTG.
What does it do?
It is a rolemodel on how to write a Plone Extension.
Instead of creating custom content types for Galleries, it integrates with the plone functionality to choose different views for folderish content types.
Lets try it!...
Introduction (Patrick)
----------------------
* 1684 Erweiterungen auf http://plone.org/products
* http://pypi.python.org/
* Beispiele:
* collective.plonetruegallery
* Singing&Dancing
Installing Addons (Patrick)
---------------------------
* in buildout eintragen (zeigen)
* /manage -> portal_quickinstaller oder -> plone_control_panel -> "Erweiterungen"
PloneFormGen (Philip)
---------------------
There a various methods to create forms in Plone:
* pure html in a view
* z3c.form, formlib or in Python deform prgrammatically
* PloneFormGen
Mit PFG kann man professionelle Formulare zusammenklicken. Wenn man bedenkt was die Alternatven sind wird klar wie cool PFG ist. Der angeblich komfortablen Formulargenerator in Typo3 ist ja schon schlimm. In Plone könnte man Formulare auch von Hand in html schreiben und in Python auslesen was oft auch eine einfache Methode ist. Wenn es komplexer sein soll dann eben z3c.forms. Aber dazu muss man ja immer programmieren. Wir machen das jetzt mal nicht sondern klicken uns ein Anmeldeformular für die Plone-Konferenz zusammen.
http://konferenz.plone.de/anmeldung
In fact the guys at fourdigts embedd the form in a iframe. Let's pretend otherwise.
* easy form to subscribe a newsletter?
* registration-form (Name, Food, Shirt-size etc.)
* Mail-Adapter
* DataSave Adapter
Internationalisation with LinguaPlone (Philip)
----------------------------------------------
* /plone_control_panel
* install installieren
* add german as language einstellen
* /@@language-controlpanel -> Deutsch und Englisch auswählen
* ZMI -> portal_languages -> "Display flags for language selection" aktivieren
* @@language-setup-folders -> Ordnerstruktur anlegen
* Englische Startseite anlegen
* Infos zum übersetzen (folder übersetzen, language_independent)
http://plone.org/products/linguaplone/issues/250
http://localhost:8080/Plone/@@language-setup-folders
Seit Plone4 ist der Standardweg von Übersetzungen, das jede Sprache
einen eigenen Folder bekommt. Wenn Inhalte übersetzt werden, wird
* die Datei automatisch in den richtigen Ordner kopiert.
Add 'bling' with PloneTrueGallery (10min) (Patrick)
---------------------------------------------------
Customizing the design with plone.app.themeeditor (20min) (Philip)
------------------------------------------------------------------
* Installation
* explain UI
* change Logo (dowmload http://www.ploneconf.org/++theme++ploneconf.theme/images/logo.png)
* change Footer (colophon): add copyright (Phone: +31 26 44 22 700
mailto:[email protected])
* change some css::
#visual-portal-wrapper {
margin: 0 auto;
position: relative;
width: 980px;
}
export customisations
---------------------
* export the customisations as an egg (ploneconf.customisations)
inspect the egg
---------------
* what is where?
* jbot, static etc.
Wir können nun das Design unserer Webseite anpassen. Wir können Erweiterungen installieren und einfache Aktionen einrichten. Aber:
* Können wir auf unserer neuen Webseite Talks einreichen?
* Können wir in einer Liste die wichtigsten Eigenschaften jedes Talks anzeigen?
* Können wir Besucher den Talk bewerten lassen?
Wir müssen oft strukturierte Daten speichern oder anzeigen können, bis zu einem gewissen Grad auch noch TTW, aber irgendwann erreichen wir eine Grenze. Wir werden im zweiten Teil zeigen, wie man neue Contenttypen anlegt und wie man neue Funktionalitäten schreibt.
5.1 Theming
===========
* Diazo
* Downloading and activating a theme
* Creating a new theme
* Diazo Theme editor
* Rules
* Old-school Themeing
* Deliverance
6. Buildout I (30min) (Patrick)
===============================
Buildout erhält eine Liste mit Dingen die man haben möchte, und baut diese zusammen. Es übernimmt dafuer zwei Aufgaben. Eine Aufgabe ist das Holen aller eggs die man braucht, zum anderen erzeugt es bei Bedarf Konfigurationsdateien und Verzeichnisse. Plone benötigt zum Beispiel ein Verzeichnis fuer Log Dateien, eines für die Datenbank und mehrere Konfigurationsdateien für sich selbst. Diese werden alle durch Buildout gebaut. Wir haben durch den Unified Installer schon ein Set an Konfigurationsdateien bekommen. Diese gehen wir nun im Schnelldurchgang durch.
Generell verwenden die Konfigurationsdateien eine Syntax die ähnlich ist wie bei ini files. Man schreibt einen Parameternamen, dann ein Gleichheitszeichen, und dann einen Wert. Wenn man in der nächsten Zeile einen weiteren Wert einträgt, und diesen einrückt, werden beide Werte als eine Liste gespeichert. Beispiel::
parts = alpha
beta
Zusätzlich gibt es Buildout Erweiterungen die eigene Einstellungen brauchen. Damit es da keine Überschneidungen gibt, teilt man seine Konfiguration in Sektoren auf, eine Sektion beginnt mit dem Sektionsnamen in eckigen Klammern. Zu guter letzt verwenden einige Erweiterungen die gleichen Einstellungen, um diese dort wieder nutzen zu können, schreibt man keinen konkreten Wert sonderne eine Referenz auf das Ursprungsfeld.
* buildout.cfg
Wenn man buildout ausführt, sucht buildout zuerst nach dieser Datei.
Die Buildout Sektion vermischt hier Buildout Konfigurationen und
wichtige Parameter die von mehreren Erweiterungen verwendet werden.::
extends =
Hier wird gesagt, welche weiteren Konfigurationsdateien noch geladen
werden. Die Reihenfolge ist wichtig!::
http-address =
Der Port auf dem Plone laufen wird.::
effective-user =
eggs =
Die Softwarepakete die wir haben wollen. Hier kommen die
Erweiterungen rein.::
develop =
Hier müssen links rein auf die Verzeichnisse in denen der Quelltext
eigener Pakete sind.
parts =
Ich habe bisher den Begriff Erweiterung verwendet für die
Erweiterungen, in buildout heissen sie aber in wirklichkeit recipes.
Wie ein Rezept kann man dann weitere Dinge installieren lassen.
Wenn man tatsächlich ein Recipe einmal oder mehrfach verwendet,
nennt man die Sektion einen Part.
Hier trägt man ein, welche Parts tatsächlich verwendet werden
sollen. Wenn man einen Part geschrieben hat, und nach einem buildout
ist nicht das passiert, was man erwartet hat, liegt es
wahrscheinlich daran, das man vergessen hat, diesen Part
einzutragen.
[versions]
Wichtig und nervig zu gleich.
Wenn man ein Softwarepaket braucht, schreibt man nur den Namen, und
buildout versucht, das aktuellste Egg zu holen.
Wenn man auf einem neuen Rechner das selbe buildout zum ersten mal
laufen lässt, hat man deswegen im Zweifel anderne Code, und wundert
sich, warum das Plone auf dem einen Rechner läuft und auf dem
anderen nicht. Um das zu vermeiden, muss man immer alle Versionen
runter schreiben. Der Unifiedinstaller hat eine Buildouterweiterung,
welche alle Pakete auflistet, bei denen man kein Versionspinning
gemacht hat. das kann man direkt kopieren.
In diese Datei trägt man diese Pakete übrigens nicht ein.
* base.cfg
Hier ist die grundlegende Plone Struktur eingetragen, wobei alle
Werte die man vielleicht ändern wollen würde aus der [buildout]
Sektion geholt werden. Diese wurde in buildout.cfg zusammengestellt.
* versions.cfg
Hier werden alle Versionen gepinnt. In diesen Dateien trägt man
normalerweise eigene Versionen ein.
Diese ganzen Dateien werden normalerweise von Zope/Plone auf einem
Webserver bereitgestellt. Die Dateien haben alle einen
auskommentierten Link auf die Quelle. Man kann diese URLs auch
direkt auskommentieren und auf die neuesten Plone Versionen zeigen
lassen.
* development.cfg
Diese Datei hat die gleiche Aufgabe wie buildout.cfg. Buildout.cfg
konfiguriert das Plone so, wie man es Produktiv verwenden sollte,
develop.cfg konfiguriert es so, wie es einem Entwickler hilft.
Everybody hates buildout, but there is nothing better.
Zope 2.7 was 7 MB big, thats the size of django nowadays btw.
When eggs came around, the zope community decided to hop on the bandwagon.
Make zope smaller, better defined components and all that.
Now development can go on faster, because you modify a smaller subset of the code.
Ok, now, which version is safe to use for your plone?
Plone uses about 300 Packages, all packages get new versions on their own.
Package a requires package b, but at least version 3. Package c requires
Package b, but at most version 4. Version 5 is current. This gets a mess,
but there is a solution, buildout.
Buildout will download all required eggs, check the dependencies and get the
right version of everything.
The tool is quite configurable, as such, people not only use it to download
eggs, but also to set up infrastructure. Create config files, compile a custom
version of xml, install and configure varnish, create a zope instance, and so on.
Another type of extension allows whole new functionality, like mr.developer, an
awesome way to manage your checked out sources.
You use buildout by writing a configuration file. It has an ini like style.
The configuration consists of sections, the meaning of a section is given by a recipe. There is a special buildout section, it does not declare its recipe, but other general things. Lets checkout the minimal buildout to get an example.
You see here only one part, and it declares its recipe. This is the standard recipe to create a zope instance. Each recipe is an egg, and the recipe name is the egg name. As such, you can find recipes on pypi. There is something else you should know. Everybody has his preferred default settings that he wishes to use in every buildout. You can declare this in a special file. Every time, buildout parses the buildout configuration, it also looks for ~/.buildout/default.cfg
This is the perfect place to declare cache locations. Running a buildout without such a cache directory, the first time buildout runs, it needs more than half an hour because it has to get all these eggs. By declaring all these caches, things are much much faster.
Your virtualenv already has a very special location for the caches. The point it to the directories of the unified installer. This safes us half an hour now.
We already created an, egg, lets use it. But we will not use it as an egg, we use it as a source checkout. A source checkout is like an opened egg, you can easily modify the egg. Not everything gets reloaded automatically, but some things.
While buildout lets you use source checkouts directly, there is a buildout extension thats much more sophisticated and useful, mr.developer.
With mr.developer, you can declare, which packages you want to check out from which version control system and which repository url. You can check out sources from git, svn, bzr, hg, whatever. Also, you can say that some source are in your local file system.
mr.developer comes with a command, ./bin/develop. You can use it to update your code, to check for changes and so on. You can activate and deactivate your source checkouts. If you develop your extensions in eggs with separate checkouts, which is a good practice, you can plan releases by having all source checkouts deactivated, and only activate them, when you write changes that require a new release. You can activate and deactivate eggs via the develop command or the buildout configuration. You should always use the buildout way. Your commit serves as documentation.
Now, we want to install something very important, the omelette recipe. This thing creates a very very convenient way to access all used source code. It creates a lot of symlinks to point to the real file. We will see this in more detail later. There is something special we have to take care of. Ourbuildout directory is in the shared directory, and unfortunately this does not work will a number of things, one of them is our omelette.
Lastly, later during the tutorial, we will create our own egg, for this we need a to install a program. We use another part for this. zc.recipe.egg
SHOW WEBSITE
So we do not use the defaults, but change our path.
Here you see some important property, you can reference data from other sections. This is an important property, on a big site you might have multiple zope instance with only minor differences. You can define the minor differences and pull in the general settings from a template section. This way you only need to change variables in one place.
Or, even better, if you define services that work together, you can reference each others listening interfaces. So an nginx gets the port information from the buildout.
You see, buildout is very versatile, so lets get to the warnings. It is very easy to overdo with GenericSetup, what is too much and what isn't is hard to say, some people make deployments from their buildouts, some prefer, not to do that.
Be careful how far you buy the buildout mindset. Supervisor is a program to manage running servers, its pretty good. There is a recipe for it.
SHOW WEBSITE. The configuration is more complicated than the supervisor configuration itself! By using this recipe, you force others to understand the recipes specific configuration syntax AND the supervisor syntax. For such cases, collective.recipe.template might be a better match. It just iflls the variables ofa given configuration template.
Another problem is error handling. Buildout sucks balls at error handling. You get in a weird dependency? Buildout will not tell you, where it is coming from. There is a bad egg? Your newborn gives more helpful messages after consuming a bad egg.
If there is a problem, you can always run buildout with -v, to get more verbose output, sometimes it help. If strange egg versions are requested, check the dependencies declaration of your eggs and your version pinnings. There is NO warning if uppercase and lowercase typing do not match, and for some parts of the code the casing is not an issue. Check out the ordering of your extends, use the annotate command of buildout, to see if it interprets your configuration differently. Restrict yourself to simple buildout files. You can reference variables from other sections, but you can also use a section as a whole template. We learned that this does not work well with complex hierarchies and abandoned that feature.
7. Plone-IDE's (15min) (Patrick)
================================
* Show your editor
* Sublime
* Aptana
* vim
* emacs
* Our development-setup today
Zu einer Entwicklungsumgebung gehört ein Editor mit dem man gut umgehen kann
und ein Tool mit dem man einfach eine Volltextsuche machen kann.
Ausserdem ein Python.
Jeder arbeitet anders mein Produktivitätsgeheimnis ist die
Volltextsuche im gesamten Plone Code.
8. Creating your own eggs to customize Plone (15min) (Patrick)
==============================================================
* creating plonekonf.talk with zopeskel/templer
* what's in an egg?
Eigener Code von uns muss in ein egg. Ein Egg ist eine Zip Datei oder ein
Verzeichnis das einige Konventionen einhalten muss. Wir machen es uns hier
einfach und verwenden templer. Mit templer kann man ein Anwendungsskelett
erstellen, und muss nur noch die Lücken ausfüllen.
Noch haben wir ZopeSkel aber nicht, wir müssen es noch über unser
Buildout installieren.
Dazu gehen wir nun in das src Verzeichnis, und rufen folgendes auf:
zopeskel
Dann:
zopeskel dexterity
Description: Plonekonferenz Talk
Wir gehen die Fragen durch
Wir gehen die Verzeichnisse durch
Wir tragen das Egg in buildout ein.
ZCML:
Konfigurationssprache um das Zopetoolkit Komponententsystem zu
konfigurieren
Grok:
Alternative Konfigurationssprache zu ZCML.
Genericsetup:
Konfiguration die in der Plone Datenbank gespeichert ist kann
hiermit importiert und exportiert werden.
Nachdem wir alles eingetragen haben, starten wir Zope und aktivieren die Erweiterung in Plone.
Nun noch schnell ein wenig Scaffolding für später!
Wir legen im static Verzeichnis 2 Dateien an, plonekonf.css und
plonekonf.js
Dann gehen wir in das ZMI... und tragen die Ressourcen in
portal_javascripts und portal_css ein.
Plone hat eine Ressourcenverwaltung für CSS und Javascript Dateien,
mit der man Plone noch ein wenig effizienter machen kann.
Die Standardeinstellungen hier reichen in der Regel.
Nun haben wir Anpassungen gemacht die in der ZODB gespeichert
wurden. Diese wollen aber auch versionieren, dafür ist Genericsetup
da.
Wieder im ZMI, gehen wir nun nach portal_setup, und exportieren dort
die JS und CSS Einstellungen. Wir bekommen eine ZIP Datei, welche
die XML Dateien enthält, die wir haben wollen. Wir kopieren diese in
das Profilverzeichnis und passen sie an.
Wir müssen lediglich unsere eigenen Dateien hier rein schreiben,
Genericsetup löscht nicht die anderen Einträge, und es fügt auch
nicht die Dateien doppelt ein.
If this is your first egg, this is a very special moment. We are going to create the egg with a script that pregenerates a lot of necessary files. They all are necessary, but sometimes in a sublte way. It takes a while do understand their full meaning. Only this year I learnt and understood why I should have a manifest.in file. You can get along without one, but trust me, you get along better with a proper manifste file.
Lets have a look at it.
bootstrap.py, buildout.cfg CHANGES.txt CONTRIBUTORS.txt docs/* README.txt setup.py
configure.zcml metadata.xml
9. Creating a new content-type "Talk" with Dexterity (45min) (Philip)
=====================================================================
* Dexterity - An introduction
* Creating content-types TTW
* Exporting content-types into code
What is a content-type?
-----------------------
A content-type is object that can store information and is editable by users.
Schema
A definition of fields that comprise a content-type (in Django that would be the Model)
These input to these fields can be stored in properties of an object.
python, xml or ttw
FTI
The "Factory Type Information" configures the content-type in Plone, assigns a name, an icon, additional features and possible views to it.
xml or ttw
View
A visual representation of the objecta and the content of it's fields.
Written as python and zope page templates (a templating language)
Dexterity and Archetypes - A Comparison
---------------------------------------
There are two content-frameworks in Plone
* Dexterity is relatively new. Will be core in Plone 4.3 (4.3a2 is here to test)
* Archetypes is old, tried and tested (Around since Plone 1.0.4)
* Archetypes: Very widespread, almost all existing addons are based on Archetypes
* Plone's default content-types are Archetypes (unless you use plone.app.contentypes)