[PDF Download] Core data in swift data storage and management for ios and os x 1st edition marcus za
Visit to download the full and correct content document: https://textbookfull.com/product/core-data-in-swift-data-storage-and-management-for-i os-and-os-x-1st-edition-marcus-zarra/
More products digital (pdf, epub, mobi) instant download maybe you interests ...
Data Deduplication for Data Optimization for Storage and Network Systems 1st Edition Daehee Kim
Marcus’s books have long been my go-to recommendation for people who want to learn about Core Data. With new information for beginners and experts alike, they are a great insight into how you should be using Core Data and the features that it offers.
➤ Daniel Tomlinson
Senior software engineer, Rocket Apps Ltd.
Marcus has a profound understanding of Core Data, and this book describes not only the basics of working with Core Data, but also how to do so in a performant manner, with explanations and examples. This is an indispensable reference, alongside Apple’s documentation, and one that will quickly make Core Data your go-to persistence mechanism. You’ll be able to deal with anything that comes up with confidence.
➤ Abizer Nasir
Lead developer, Jungle Candy Software Ltd.
A compelling book, packed with useful information.
➤ Steven Oxley Senior engineer, Social Native
We've left this page blank to make the page numbers the same in the electronic and paper books.
We tried just leaving it out, but then people wrote us to ask about the missing pages.
Anyway, Eddy the Gerbil wanted to say “hello.”
Core Data in Swift
Data Storage and Management for iOS and OS X
Marcus S. Zarra
The Pragmatic Bookshelf
Raleigh, North Carolina
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf, PragProg and the linking g device are trademarks of The Pragmatic Programmers, LLC.
Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein.
Our Pragmatic books, screencasts, and audio books can help you and your team create better software and have more fun. Visit us at https://pragprog.com
The team that produced this book includes:
Jacquelyn Carter (editor)
Potomac Indexing, LLC (index)
Liz Welch (copyedit)
Gilson Graphics (layout)
Janet Furlow (producer)
For sales, volume licensing, and support, please contact support@pragprog.com.
For international rights, please contact rights@pragprog.com
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher.
Printed in the United States of America.
ISBN-13: 978-1-68050-170-4
Encoded using the finest acid-free high-entropy binary digits.
Book version: P2.0 July 2016
Introduction
It’s amazing to realize that as of the writing of this book, Core Data is over 12 years old. That’s an incredible number when you consider that it’s more powerful and more popular today than it has ever been. For a framework, that’s pretty spectacular.
In this book we discuss Core Data and work with the framework from the perspective of Swift. Swift is a young language and has a lot of growing yet to do, but its popularity can’t be denied.
It’s clear that Swift is important to Apple and therefore should be equally important to developers who work on Apple’s platforms.
Is This Book for You?
If you plan on writing an application that saves data to disk, then you should take a very long look at Core Data. Whether you’re focusing on the desktop or the iPhone, Core Data is the most efficient solution to data persistence.
A good way to confirm that you know enough Cocoa to benefit from this book is to take a look at Chapter 1, Before We Begin, on page 1. You should find it dense, but every step should be familiar to you.
What Is Core Data?
In the simplest terms, Core Data is an object graph that can be persisted to disk. But just like describing a man as a “bag of mostly water,” that description hardly does Core Data justice. If you have worked with Interface Builder (specifically on OS X), you know that it effectively removes a third of the coding from the Model-View-Controller (MVC) design pattern. With Interface Builder, developers don’t need to spend countless hours writing and rewriting their user interface to make sure that it’s pixel perfect. Instead, they simply drag and drop the elements in the IDE, bind them together, and call it done.
Of course, the problem with Interface Builder is that we still need to code the other two parts! Both the controller and the model need to be developed in code and made to work with the interface we just designed. That’s where Core Data comes in. In a nutshell, Core Data deals with a third of that MVC design: Core Data is the model.
It is a common misconception that Core Data is a database API for Cocoa that allows a Cocoa application to store its data in a database. Although that description is factually accurate, Core Data does a lot more. It serves as the entire model layer. It’s not just the persistence on disk; it’s also all the objects in memory that we normally consider to be data objects. If you have experience working with Java, C#, or some other object-oriented language, the data objects take a lot of time to write, and they’re generally very repetitive in nature. Core Data eliminates most, if not all, of that boilerplate code for us and lets us focus on the business logic, or the controller layer, of our application. It does this with an interface that’s as easy to use as Interface Builder.
In addition to ease of use, Core Data is highly flexible. If we need to step in and change the functionality of some portion of the data model, we can. From how a value is handled when it’s being accessed to how data is migrated from one persistent store to another, we can choose how little or how much we want to code ourselves and how much we want Core Data to do for us.
When you start to learn Core Data, it’s best to think in terms of objects. Core Data is a framework designed to manage your data and data object graph. As a secondary function, it will persist that data to disk. However, its primary function is to manage the objects.
Online Resources
The app and examples shown in this book can be found at the Pragmatic Programmers website for this book.1 You’ll also find the community forum and the errata-submission form, where you can report problems with the text or make suggestions for future versions.
This is a book with two beginnings and one ending. The ending should be obvious: to increase your knowledge and understanding of Core Data.
Of the two beginnings, you get to choose. If you’re relatively new to either iOS development or Swift, then please read this chapter; it was written for you.
If, on the other hand, you’re intimately familiar with iOS perhaps you even prefer to build your test cases in your own way then I suggest you jump to Chapter 2, Under the Hood, on page 13. The chapter you’re currently reading focuses on building a test application.
Test Application
When you’re learning how to write software using Swift or when you’re first learning how to develop an iOS application, the book that’s helping you generally starts at zero, often referred to as the “Hello World” application.
This is not that kind of book. For us to explore Core Data a certain level of knowledge is necessary a foundation of knowledge that we can build upon.
This book expects that you understand the fundamentals of Swift. It’s written in a such a way that you don’t need to be a master of Swift. We aren’t going to be doing any complex coding using the unusual bits of Swift. We’re intentionally avoiding those.
The focus of this book is to increase your knowledge of Core Data while working in the Swift environment. Therefore, the code is as straightforward as I can make it.
On our journey to learn about Core Data, we’re going to use an original iPhone recipe application. While the application itself is fairly complex and contains a large number of views, the concepts behind these views are standard and
Chapter 1. Before We Begin • 2
will be familiar to anyone who has done work in Cocoa. If you haven’t yet mastered Swift and Cocoa, then I highly suggest you review Chris Adamson and Janie Clayton’s iOS 9 SDK Development, published by the Pragmatic Bookshelf.
Our goal in this chapter is to establish a baseline application from which to work. Core Data is a supporting framework, and we need something for it to support in order to explore and demonstrate its features and characteristics. This recipe application is the foundation used in the book. You can use this chapter as a reference of the overall picture of the application as we’re exploring the inner workings of Core Data in the rest of the chapters.
If you’re already comfortable with storyboards and the creation of iOS applications, feel free to skim the provided code sample and jump to Chapter 2, Under the Hood, on page 13, in which we’ll begin to dive into the substance of Core Data.
The Transmission of a Car
When I describe Core Data to nonprogrammers, I tend to use a car analogy.
If you were a car mechanic and wanted to learn how to work on transmissions, you’d buy a book that was specific to transmissions. However, that book wouldn’t teach you how to build a car; it’d dive right into the workings and theories of a transmission.
The differences between car mechanics and programming show up right away. The author of the book can be reasonably certain that the reader will have access to a car and that it is already going to have a transmission built in that the reader can use to apply the knowledge from the book. This isn’t necessarily true in programming.
Since I can’t be certain that you have an application in your possession that contains Core Data already, I’m including one with this book. This chapter gives you a car to tinker with while we explore the transmission.
The Storyboard
To keep the structure of our application as simple as possible, we’ll use a storyboard to design the entire UI of our iPhone application. As you’ll recall from your reading or experience, a storyboard allows us to view the entire application interaction in one place. We can also control a greater portion of the UI within the storyboard and thus allow for even less code to be introduced to our project. You can see a zoomed-out version of our storyboard in the following screenshot on page 3.
What Is a Storyboard?
When non-Apple developers think of storyboards, they think of playing with application flow and designs probably on a napkin or a whiteboard. However, with Apple’s development tools, the word “storyboard” has a different meaning.
Within Xcode is a visual design tool called Interface Builder. Interface Builder can produce a file referred to as a “storyboard.” These storyboards can be all or part of an application’s user interface. It’s possible for every visual element within an application to be stored inside a single storyboard file.
These storyboard files get compiled into the application and are used when the application is run to display the user interface. They’re the latest iteration of Apple’s user interface tool that previously produced “nib” and “xib” files.
This storyboard seems complex and it is. However, most of the code needed to support these views is minimal, and there’s a fair amount of view controller reuse that will make the application easier to develop and maintain.
There are three primary elements to this application: a list of recipes, a detailed view of a single recipe, and the ability to add/edit recipes. The add/edit feature is the most complex, so we’ll save it for last.
The Source Code
To avoid making you copy the code and designs out of this book, all of the source code is available for download at www.pragprog.com.
Chapter 1. Before We Begin • 4
The Recipe List
When users launch our application, they’re immediately presented with a list of recipes. The list is represented in the storyboard as a UITableView with a prototype cell. We’re using a basic cell in the prototype, as shown here.
Associated with this UI element in the storyboard, we also have a UIViewController named PPRMasterViewController. The data for this UITableViewController is driven by an NSFetchedResultsController (which we explore in detail in Chapter 3, iOS: NSFetchedResultsController, on page 33). Right now we’re concerned with the segues of this UIViewController. The segues describe the transition that our application uses when going from one view controller to another. A segue can happen when we select a row in a table, a button in the navigation bar, a button on the tab bar, or virtually anything that causes the UI to move to another view controller.
When a segue is activated, the current UIViewController receives a call to prepareForSegue(:sender:). That’s our opportunity to prepare the next UIViewController for display. It’s a good idea to use this method as a branching point for each potential segue. Taking this step aids with code clarity and maintenance. With one or two segues, this method is fairly easy to maintain. However, when we have many possible segues, the code quickly becomes unwieldy. Instead of waiting for the code to become unwieldy and refactoring it, we start off by using this method as a branching point.
PPRecipes/PPRecipes/PPRMasterViewController.swift
func prepareForDetailSegue(segue: UIStoryboardSegue){ let control=segue.destinationViewController as!PPRDetailViewController let path=tableView.indexPathForSelectedRow! let recipe=fResultsController!.objectAtIndexPath(path) as!PPRRecipeMO control.recipeMO=recipe
}
The first segue brings in the PPRDetailViewController and displays a single recipe in detail. The method prepareForDetailSegue(:) demonstrates the dependency injection pattern. We obtain a reference to the about-to-be exposed UIViewController, and we inject the information that it needs. We’ll use this pattern extensively throughout the book.
PPRecipes/PPRecipes/PPRMasterViewController.swift
func prepareForAddRecipeSegue(segue: UIStoryboardSegue){ let tempController=segue.destinationViewController let controller=tempController as!PPREditRecipeViewController let moc=managedObjectContext! let recipe= NSEntityDescription.insertNewObjectForEntityForName("Recipe", inManagedObjectContext:moc) as!PPRRecipeMO controller.recipeMO=recipe }
The second segue branches us into the editing capabilities of our application. This is our first bit of code reuse.
Instead of having an “add” logic path and an “edit” logic path, the paths are combined. In fact, their functionality is 99 percent identical. The 1 percent difference between them concerns whether an object is being created or an existing object is being edited. By again using dependency injection, we pull that 1 percent difference out of the logic path and let the parent UIViewController make the decision. As far as the rest of our editing workflow is concerned, there’s no difference. It’s being handed a data object, and it doesn’t matter whether the object has been created anew or whether it previously existed.
The Recipe Detail
When users select a recipe in our application, we want to display everything about the recipe in one screen so they can easily absorb the information and prepare the recipe. We’ll need one fairly complex UIViewController in order to give them that one-screen access. Take a look at the following screenshot for a sample of the view.
In our UIViewController, we’ll take the data object that was passed to us and display it in one (potentially) lengthy UIScrollView.
The edit button in the UINavigationBar is the interesting part of this view controller. When the edit button is tapped, we enter the edit workflow (we’ll discuss this further in the next section). This process is identical to the add workflow we discussed in The Recipe List, on page 4. With this code reuse, we can now enter the same workflow from the view controller that allows us to view a recipe as we did from the list recipes view controller. Both of these produce the same effect: we can edit a recipe, and it doesn’t matter if that recipe is new or existing.
PPRecipes/PPRecipes/PPRDetailViewController.swift overridefunc prepareForSegue(segue: UIStoryboardSegue,sender: AnyObject?){ guardlet identifier=segue.identifier else { fatalError("Unidentifiedsegue") } assert(identifier== "editRecipe", "Unexpectedidentifier:\(identifier)") let controller=segue.destinationViewController as!PPREditRecipeViewController controller.recipeMO=recipeMO } Chapter 1. Before We Begin
Note the subtle difference in this reuse. In the previous version of the edit workflow, we created a new data object. In this version, we take our existing reference to the data object and hand it off to the edit workflow.
The Edit Workflow
The complexity of our application really lives in the edit workflow shown here. It is in this workflow that we edit, delete, and change data objects.
The bulk of the complexity of the edit workflow is in the very first UIViewController. To begin with, this UITableViewController uses static cells, as opposed to prototype cells. In this design, we have a known quantity of cells, and each cell displays a different piece of information.
By utilizing static cells, we do a significant portion of the work of the edit workflow directly in the storyboard. We avoid handling a large amount of complexity in our application when a user selects a cell. In other words, instead of having to figure out which cell was selected, determine the view controller to build, populate that view controller, present it, and so on, we
can have the storyboard do the bulk of that work for us. Each cell in this UITableViewController has a segue to another UIViewController. Each of those segues is named, and we can therefore do away with a large portion of code. Our UITableViewController subclass needs to look only at the identifier of the segue and inject the right dependencies.
switch identifier{ case "editRecipeName": prepareForEditRecipeNameSegue(segue.destinationViewController) case "selectRecipeType": prepareForSelectTypeSegue(segue.destinationViewController) case "selectNumberOfServings": prepareForSetServingsSegue(segue.destinationViewController) case "selectLastUsed": prepareForSetDateSegue(segue.destinationViewController) case "selectAuthor": prepareForSelectAuthorSegue(segue.destinationViewController) case "selectIngredients": prepareForSelectIngredientSegue(segue.destinationViewController) case "editDescription": prepareForDirectionsSegue(segue.destinationViewController) default: fatalError("Unrecognizedsegue:\(identifier)") }
Here we see the value of using the -prepareForSegue:sender: method only for branching. Had we put all of the flow logic into this one method, it would easily be 100 lines of code or more and be a mess to maintain.
All of the UIViewController instances that are accessed from the edit UITableViewController fall into one of two categories: edit something or select something. Let’s look at an example of both kinds of instance. See the following screenshot. Chapter
Text Edit View Controller
The PPRTextEditViewController is easily the most reused UIViewController. The bulk of a recipe is text, and the text is probably going to need to be edited. As a result, the process of editing in our application must be highly reusable. This is also a great opportunity to use a block callback to assist in the reusability of the PPRTextEditViewController.
controller.text=recipeMO?.valueForKey("name") as?String controller.textChangedClosure={(text: String) in self.recipeMO?.setValue(text,forKey: "name")
let path= NSIndexPath(forRow:0,inSection:0) let cell= self.tableView.cellForRowAtIndexPath(path) cell?.detailTextLabel?.text=text } }
The most interesting part of this segue preparation is the callback. The PPRTextEditViewController is actually quite dumb. Its entire job is to consume the text entered into a text field and listen for either the Done button to be clicked or the Return key to be tapped. When either of those happen, it takes the text from the UITextField (or the UITextView) and passes it to the callback block.
Note that the block accepts a string and expects the closure to throw an error if it’s appropriate. The parent, which defines the block, then validates the text and throws the error if there’s a problem. The PPRTextEditViewController receives a pass/fail from the block. In the event of a failure, it displays the error. If the block returns a pass, the text view controller pops back to its parent.
With this design, we can use the PPRTextEditViewController to edit any piece of text we choose, and it doesn’t need any custom or special handling code. The only thing we need to do for each instance is set up its view in the storyboard and pass in the text that it needs to start with. By customizing the view, we also gain access to which keyboard is appropriate for each text edit, thereby making it easy to reuse this UIViewController for numeric text, email addresses, or virtually any data we can think of.
The second function of the callback block is to update the data object and the edit view. Since we’re using static cells, we must grab a reference to the existing cell and refresh it based on the text being passed into the block.
List Ingredients View Controller
While there are a couple of “select something” items in the PPREditRecipeViewController, the ingredients selection is by far the most interesting. First, we want to display all of the existing ingredients. To do this, we need a selection view controller. Next, we want to add ingredients, which means we have to add an Add Ingredient row when the user taps the Edit button. When users select the Add Ingredient row, we put them into another view controller that allows them to edit the individual components of an ingredient. In the Add Ingredient view, we allow users to set the quantity, type of ingredient, and unit of measure. The end result can be seen in the following screenshot on page 11.
Later, as we update and enhance our application, this workflow becomes even longer and more complicated. Fortunately, the code stays quite sane with the reuse of view controllers and the use of the storyboard.
Unfortunately, we need to build two specific view controllers for this workflow: one to handle listing the ingredients (including adding and deleting) and one for adding an ingredient. Luckily, we can get a lot of reuse from our text edit view controller in this part of the application.
Ready for Core Data
The story now merges from the two beginnings. In the next chapter we’ll dive into the structural components of Core Data, walk through each of the pieces, and see how they fit into the puzzle.
At the end of that chapter, you’ll have a firm understanding of the Core Data stack and how to access it. From there we’ll begin to utilize some of the more advanced concepts behind Core Data to improve on our application.
You can download the source code for this application (and the future changes we’re going to introduce) at PragProg.com.1
1. http://www.pragprog.com
CHAPTER 2
Under the Hood
In the previous chapter you may have read about the application we’ll be using as our structure for most of the rest of the book. If you’re the type who prefers to build your own test cases and/or have extensive experience building iOS applications, then you’ve most likely skipped ahead to this chapter. Even so, the first chapter is a good reference to see how the baseline application used throughout this book was developed.
Part of the barrier to entering the world of Core Data is that it’s perceived as having a steep learning curve. Looking at the code samples that Apple provides for developers, you might at first glance agree with that evaluation. That perception was born from the first few iterations of the framework. When Core Data was first introduced, there was a large amount of confusion over what needs to be done, what doesn’t need to be done, and what we’re allowed to do with the framework. A lot has changed since those early days. As you’ll see in the next couple of chapters, Core Data is very easy to use, and when you need the complexity to handle an edge case, the options are available.
In my experience of working with and writing persistence layers for various languages, I’m constantly amazed at how simple and elegant the Core Data API is. There’s very little overlap in functionality between the individual pieces of Core Data no wasted space or unnecessary redundancy. Because Core Data is built on the infrastructure of Objective-C (Core Data hasn’t been rewritten into Swift yet) and Core Foundation, it doesn’t seek to duplicate functionality that already exists in other parts of the overall API but instead uses that functionality to its fullest extent.
In this chapter, we go through the key pieces of Core Data and remove some of the mysticism that surrounds them. By the end of this chapter, you’ll have a much higher comfort level and will be able to understand what all of that sample code does. We’ll also be discussing the terminology of Core Data so
Chapter 2. Under the Hood • 14
that you can better understand what the individual components are and how they work together.
At its most basic level, Core Data is an object graph designed to manage data objects. It’s common when you’re first approaching Core Data to think of it as an object-relational mapping framework and in truth, it can be used as such. However, that isn’t the best approach. My elevator pitch for Core Data goes like this: “Core Data is an object graph that can persist to a database.” The primary function of Core Data is to manage the object graph. Persisting the data to disk is a secondary, although vital, function.
The Core Data API, or stack as it’s commonly called, consists of three primary pieces: the NSManagedObjectModel, the NSPersistentStoreCoordinator, and the NSManagedObjectContext, as shown here.
All of these pieces work together to allow a program to retrieve and store NSManagedObject instances. In most situations, the program will access the NSManagedObjectContext only once the stack has been created. It’s possible to access the other components of the stack, but it’s rarely necessary. Each of the three pieces of the Core Data stack work together. As we’ll review in detail, the NSManagedObjectModel feeds structure to the NSPersistentStoreCoordinator and the NSPersistentStoreCoordinator feeds data and structure to the NSManagedObjectContext. The NSManagedObjectContext in turn handles requests from the rest of the application to create, update, delete, and insert NSManagedObject instances.
Throughout this chapter, and most of the rest of the book, we’ll be referencing the application that we built in Chapter 1, Before We Begin, on page 1. We’ll start that reference by exploring the creation of the Core Data stack.
Introducing the NSManagedObjectModel
The first part of our exploration of the components of Core Data is the portion of the framework that’s the least accessed: the NSManagedObjectModel. An object model is a way to describe the data in terms of objects. The NSManagedObjectModel is a compiled, binary version of the data model that we create graphically in Xcode. When we say that we’re manipulating the object model, we mean we’re editing the source file in Xcode that will get compiled and used by the NSManagedObjectModel. From a database perspective, this file represents the schema of the database. In Xcode, this file is shown in two different styles; the easiest to recognize is shown here.
While this view is great for conceptualizing the data and the objects, it’s not great for editing. Therefore, the style can be changed using a control in the lower-right corner called Editor Style. The second style is shown here.
Chapter 2. Under the Hood • 16
The NSManagedObjectModel and, by extension, the associated source file in the object model is what we think of when we need to change the object model. The source file is saved as an xcdatamodel file. That file is stored within a Cocoa style bundle that starts out with the same filename. If you were to look at the file structure directly you would see a folder with the xcdatamodeld extension and then you’d find the actual data model file inside. The reason for this structure is explained in Chapter 4, Versioning and Migration, on page 47. Xcode understands how to compile these files in this bundle. When Xcode encounters these files during the compile process of a project, it compiles them into a binary form ending with the extension mom inside of a bundle with the momd extension. We can also build these files from the command line using the momc tool.
Editing the Data Model
In Chapter 1, Before We Begin, on page 1, the sample project started with the data model already created. Let’s look at how that that data model was created. To begin with, we told Xcode to create a new file (File > New > File…), and we selected Data Model from the template, as shown here.
This presents us with a blank data model ready to be edited. From here, in grid view, we added the three entities being used in the project: Recipe, RecipeIngredient, and Type. We then added the attributes and relationships for each of those entities. For a discussion of entities, attributes, and relationships, take a look at Working with NSManagedObject Instances, on page 21.
Loading the Data Model
Once we’ve created the source file for the data model, we need to instantiate it within our application. In the Xcode sample projects, this is generally done in its own method in the application’s AppDelegate. However, this process is unnecessary and tends to add to code bloat in the AppDelegate. My preference is to treat Core Data, really the entire persistence layer, as a first-class citizen in the application. What this means is that we can create a new controller that’s a subclass of NSObject and place all of the Core Data–related code into that controller. From there we can instantiate that controller within the Application Delegate.
Further, I like to construct the entire Core Data stack in a single method. There’s rarely a situation where you wish to build only part of the stack. With that structure, you can kick off the initialization of the Core Data stack as soon as the application launches so that it’s available, in some form, immediately. Therefore, in our sample application, we have a method named -initializeCoreDataStack that starts off with constructing the data model.
To initialize the NSManagedObjectModel, we first need to locate it within the application bundle. We call on the NSBundle and retrieve the -mainBundle, which represents the application bundle. From there, we call -URLForResource:withExtension: using the name of our data model in this case PPRecipes and the extension momd. We use a guard to verify that we did receive an NSURL. We then initialize the NSManagedObjectModel with that NSURL. We again verify that everything worked correctly by using a guard against the initialization.
And that’s everything involved in constructing the NSManagedObjectModel. Our next step is to construct the NSPersistentStoreCoordinator, which uses the NSManagedObjectModel we just initialized.
Integrating with the NSPersistentStoreCoordinator
The NSPersistentStoreCoordinator is the true maestro of Core Data. The NSPersistentStoreCoordinator is responsible for persisting, loading, and caching data. Think
of the NSPersistentStoreCoordinator as the heart of Core Data. Having said this, we do very little work with the NSPersistentStoreCoordinator directly. We work with it upon initialization, but we almost never touch it again over the life of the application.
As part of our initialization, we perform two steps with the NSPersistentStoreCoordinator. First, we initialize it, which requires a valid NSManagedObjectModel. Once it’s initialized, we add one or more NSPersistentStore instances. An NSPersistentStore is a representation of a location in which the data is saved/persisted. Typically, this persistence is done to disk. However, that step isn’t required; it could be in memory or even over the network. For now, let’s focus on disk persistence. The NSPersistentStore is responsible for describing the file format used. This file format can be one of several: SQLite, binary, or atomic. (There’s also an XML store for OS X, but I don’t recommend using it because it isn’t available on iOS, nor does it perform very well.) To keep our focus, we’ll use the SQLite format in this first iteration of our application and explore the other formats later in the book.
In previous versions of Core Data and the sample projects, the initialization of the NSPersistentStoreCoordinator and the addition of the NSPersistentStore were done in a single method. This example tended to lead to a number of issues for developers because they didn’t fully understand the impact of the example. Therefore, we’re going to do this initialization in a more complex way, but it will be a way that won’t paint us into a corner.
PPRecipes/PPRecipes/PPRDataController.swift
let psc= NSPersistentStoreCoordinator(managedObjectModel:mom)
In this first bit of code, we initialize the NSPersistentStoreCoordinator and pass it the NSManagedObjectModel that we previously initialized. This call returns immediately, therefore we can do it in line as part of the startup of the application.
Adding one or more NSPersistentStore instances to the NSPersistentStoreCoordinator, however, can take an unknown amount of time. The reason for the unpredictability is that we could also be performing a migration during the call (as discussed in Chapter 4, Versioning and Migration, on page 47), or we could be linking and updating with iCloud (as discussed in Chapter 9, Using Core Data with iCloud, on page 123). If either of those situations occurs, the addition of the NSPersistentStore can delay the launch of the application to the point of providing a poor user experience or, worse, being terminated by the operating system. To avoid either of these situations, we want to add the NSPersistentStore on a background queue so that the application can finish launching while we perform our startup.
PPRecipes/PPRecipes/PPRDataController.swift
let queue=dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0) dispatch_async(queue){
let fileManager= NSFileManager.defaultManager() guardlet documentsURL=fileManager.URLsForDirectory(.DocumentDirectory, inDomains:.UserDomainMask).first else { fatalError("Failedtoresolvedocumentsdirectory") }
let storeURL=documentsURL.URLByAppendingPathComponent("PPRecipes.sqlite") do { try psc.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL:storeURL,options: nil) } catch { fatalError("FailedtoinitializePSC:\(error)") }
In this portion of the code, we grab a reference to a global queue with a default priority. Then we add a block to be executed on that queue that will handle the addition of the NSPersistentStore to the NSPersistentStoreCoordinator.
Inside that block, we first determine where we want to store the file associated with our NSPersistentStore. In this example, we’re going to put it into the Documents directory that’s part of the application sandbox. If we were working on OS X, we could put it in the Application Support folder or anywhere else that was appropriate. We resolve this path using the NSFileManager and call its URLsForDirectory(:inDomains:) method, which will return an array of NSURL instances. We call first on that array to retrieve the last NSURL. We then append the filename for our NSPersistentStore to the end of that NSURL.
With the location of the store now resolved, we can add the NSPersistentStore to the NSPersistentStoreCoordinator. We do this with a call to addPersistentStoreWithType(: configuration:URL:options:). This is a complex method call, so let’s break it down by parameter. There are four in all.
• The first parameter is Type. This tells the NSPersistentStoreCoordinator what type of store we want initialized. In this case, we’re passing NSSQLiteStoreType to indicate we want a SQLite store. This is the parameter to change if we want to use another store type.
• The second parameter is configuration. This is an advanced setting that allows us to partition our data model into different configurations for different uses. Since we aren’t partitioning our data model at this time, we’ll pass nil, which tells the NSPersistentStoreCoordinator that we want to use the default configuration.
Another random document with no related content on Scribd:
The Project Gutenberg eBook of Malmedy und die preußische Wallonie
This ebook is for the use of anyone anywhere in the United States and most other parts of the world at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this ebook or online at www.gutenberg.org. If you are not located in the United States, you will have to check the laws of the country where you are located before using this eBook.
Title: Malmedy und die preußische Wallonie Skizzen und Studien
Author: Tony Kellen
Release date: October 4, 2023 [eBook #71803]
Language: German
Original publication: Essen (Ruhr): Fredebeul & Koenen, 1897
Credits: Jens Sadowski, Richard Scheibel, Reiner Ruf, and the Online Distributed Proofreading Team at https://www.pgdp.net (This file was produced from images generously made available by The Internet Archive)
Anmerkungen zur Transkription
Der vorliegende Text wurde anhand der Buchausgabe von 1897 so weit wie möglich originalgetreu wiedergegeben. Typographische Fehler wurden stillschweigend korrigiert. Ungewöhnliche und heute nicht mehr verwendete Schreibweisen bleiben gegenüber dem Original unverändert; fremdsprachliche Ausdrücke wurden nicht korrigiert.
Verschiedene Schreibweisen, insbesondere bei Personen- und Ortsnamen, wurden nicht vereinheitlicht, sofern die Varianten mehrmals im Text auftreten. Auch die Verwendung der Umlaute Ä und Ü, bzw deren Umschreibung Ae und Ue, ist nicht einheitlich; dies wurde ebenso belassen.
Die Fußnoten wurden an das Ende des jeweiligen Kapitels verschoben.
Das Original wurde in Frakturschrift gesetzt. Passagen in Antiquaschrift werden hier kursiv wiedergegeben. Abhängig von der im jeweiligen Lesegerät installierten Schriftart können die im Original g e s p e r r t gedruckten Passagen gesperrt, in serifenloser Schrift, oder aber sowohl serifenlos als auch gesperrt erscheinen.
Malmedy und die preußische Wallonie.
Skizzen und Studien von
A. Kellen.
Essen (Ruhr) 1897.
Verlag von Fredebeul & Koenen.
Alle Rechte vorbehalten.
Druck von Fredebeul & Koenen in Essen.
Vorwort.
ie vorliegende Schrift soll zum ersten Mal den Versuch machen, die Aufmerksamkeit weiterer Kreise in Deutschland auf Malmedy, den Hauptort der preußischen Wallonie, zu lenken. Dieser vorgeschobene Posten in des deutschen Reiches Westmark, der einst eine hervorragende Stätte der Kultur war, aber durch die Ungunst der Verhältnisse das Schicksal der vom großen Verkehr abseits liegenden Eifel teilte, verdient wohl, daß seine Geschichte und seine Eigentümlichkeiten bekannt werden. Die Stadt selbst, die in einer an Naturschönheiten reichen Gegend liegt, entwickelt sich jetzt, dank der Thatkraft ihrer Bürger, zu einem Badeort, dessen Mineralquellen denjenigen der unweit an der Grenze gelegenen belgischen Stadt Spa erfolgreiche Konkurrenz machen können.
Durch einen mehrmaligen Aufenthalt in Malmedy habe ich die dortigen Verhältnisse aus eigener Anschauung kennen gelernt; auch haben Einheimische wie Altdeutsche mir in bereitwilligster Weise Material für dieses Werkchen, von dem voriges Jahr ein Teil in der Unterhaltungsbeilage zur „Täglichen Rundschau“ erschienen ist, zur Verfügung gestellt.
Möge es dieser Schrift gelingen, in Deutschland einiges Interesse für das bis jetzt so wenig beachtete Malmedy und die preußische Wallonie zu wecken!
Essen/Ruhr, Frühjahr 1897. Der Verfasser.
I.
Einleitung.
Einige Jahre hindurch hatte ich die Verhältnisse in ElsaßLothringen studiert und besonders dem Vordringen des Deutschtums in den französischen Sprachgegenden mein Augenmerk zugewandt. Es wurde nun der Wunsch in mir rege, auch eine andere Gegend kennen zu lernen, die, abgesehen von ihrer geringeren Ausdehnung, ähnliche Verhältnisse aufweist, nämlich die preußische Wallonie. Diese Bezeichnung mag manchem Leser wenig oder gar nicht bekannt sein. Thatsächlich ist aber ein bedeutender Teil des Kreises Malmedy wallonisch und die Stadt gleichen Namens ist der Hauptort der sogenannten preußischen Wallonie. Die Bewohner dieser seit 1815 zu Preußen gehörigen Gegend sprechen wallonisch und französisch, ein Teil beherrscht auch das Deutsche. Wenn Malmedy in den Zeitungen nicht oft genannt wird, so ist das sehr begreiflich: deutschfeindliche Umtriebe kommen dort nicht vor, und man hat auch zuviel mit den Polen im Osten und den Dänen im Norden zu thun, als daß man sich mit einer verhältnißmäßig geringen Zahl Wallonen im Westen des preußischen Staates beschäftigen sollte. Dann sind auch im Südwesten des Deutschen Reiches die Elsässer und Lothringer, mit denen sich die öffentliche Meinung noch oft genug zu befassen hat. Aber merkwürdig sind die Verhältnisse doch auch in Malmedy und der Umgegend; die wenigen Notizen, die es mir gelungen war, vor meiner Reise in jene Gegend darüber zu sammeln, gaben mir keinen Aufschluß über die Fragen, die mich besonders interessirten, und so führte ich den längst gefaßten Entschluß aus, an Ort und Stelle mich über die Verhältnisse zu erkundigen.
Von Straßburg fuhr ich nach Luxemburg und von dort brachte ein gemüthlicher Bummelzug mich nach dem nördlichen Theile des Großherzogtums, dem Oesling. Die Gegend ist dort gebirgiger und rauher, als im Gutlande. Die letzte einigermaßen bedeutende Ortschaft auf großherzoglichem Boden ist Ulflingen, von den Luxemburgern Elwen genannt, während die französische Bezeichnung Trois-Vierges lautet (von drei Nornen bezw. Jungfrauen, die in früherer Zeit dort verehrt wurden). Von dort hat man bald die Grenze überschritten, und man würde im Zuge den Uebergang gar nicht gemerkt haben, wenn nicht ein Grenzaufseher nach Branntwein gefragt hätte. An der luxemburgisch-deutschen Grenze war nämlich damals noch für Branntwein eine Kontrole, weil Luxemburg, das bekanntlich zum deutschen Zollverein gehört, sich früher weigerte, die Branntweinsteuer auf gleiche Höhe zu bringen, wie in Deutschland. Dieses ist jetzt geschehen, so daß der Grenzkordon wegfallen konnte. Auch über die Grenze hinaus wird noch die Luxemburger Mundart gesprochen; die Gegend gehörte übrigens früher zum Luxemburger Lande. Die Zugverbindung war dort nicht gerade eine sehr glänzende, und so mußte ich mich schon entschließen, in St. Vith zu übernachten, weil der Nachmittagsbezw. Abendzug nicht weiter fuhr. Jetzt sind die Zugverbindungen besser.
S t . Vi t h ist ein hübsches Städtchen, und so abgelegen es auch ist, so findet man doch ein gutes Unterkommen dort. Es liegt auf einer Anhöhe und zählt ungefähr 2000 Einwohner, die mit Rücksicht auf jene Gegend als ziemlich behäbig gelten können. Außer der Viehzucht wird besonders die Gerberei eifrig betrieben. In dem Städtchen findet man eine alte Pfarrkirche, ein Kloster mit Haushaltungsschule und Touristenheim, sowie einen alten Thurm („Büchelthurm“) als letzten Ueberrest der früheren Umwallung. Die Mundart, die dort gesprochen wird, ist schon die Eifeler Mundart, die der Luxemburgischen ähnelt[1]. Die Stadt selbst nennt das Volk „Sankt Veit“ oder z’m Vekt. Wer sich über die Bevölkerung dieser Gegend unterrichten will, muß schon mit den Leuten selbst verkehren. Greift man zu einem Führer, so findet man meistens gar keine Angabe darüber. Heinrich Pflips[2], ein Eifeler Lehrer, der die Gegend beschrieben hat, beschränkt sich auf eine landschaftliche
Schilderung mit dürftigen geschichtlichen Notizen. Einige hübsche Seiten widmet Heinrich Freimuth in seinen anregend geschriebenen „Ardenner Wanderungen“[3] der Geschichte des Städtchens St. Vith.
Vormittags fuhr ich nach Malmedy weiter. Die Gegend um St. Vith ist ziemlich ärmlich, man sieht meist nur Haide und Ginster. Die nächste Station ist M o n t e n a u , eine hübsch gelegene Ortschaft mit Wäldern in der Nähe. In We i s m e s verläßt man den nach MontjoieAachen weiterfahrenden Zug, um auf einer kleinen Zweigbahn abseits nach Malmedy zu gelangen. Ich mußte in Weismes fast eine Stunde warten, und so benutzte ich die Gelegenheit, das Dorf zu besichtigen, das schon ganz im wallonischen Sprachgebiet liegt. Der Name selbst ist wallonisch und wird „Uäm“ ausgesprochen; die deutschen Bahnbeamten sprechen ihn allerdings aus, so wie er geschrieben wird: Weismes, und das kann einen Philologen schon sehr nervös machen. Das Dorf hat gar nichts Merkwürdiges; man sagte mir nur, es sei wegen seines Kirchweihfestes bekannt. Mehr interessirte mich die Schule, wo ich deutsch singen hörte. Die Bewohner grüßten mich aber meistens wallonisch oder französisch. In den wenigen Geschäften, die der Ort außer einer Strohhutfabrik aufzuweisen hat, wird auch deutsch gesprochen.
In Malmedy findet man in mehreren alten Gasthöfen, wo man deutsch, französisch oder, wenn’s beliebt, auch wallonisch sprechen kann, eine gute Unterkunft. Ein modernes Hotel wird jetzt dort errichtet. Es gefiel mir bei meinem ersten Aufenthalt so gut in dem behaglichen Städtchen, daß ich im Herbst, wo ich eine Ferienreise durch die Eifel machte, noch einmal dorthin zurückkehrte.
Bevor ich die Stadt und ihre Umgebung beschreibe, auf die Sitten und Gebräuche der Einwohner, die Sprachenverhältnisse usw. eingehe, will ich eine kurze Geschichte der Stadt Malmedy entwerfen.
[1] Dr. Hecking: Die Eifel in ihrer Mundart. Prüm, P. Plaum. 1890.
[2] Das romantische Ourthal. Ein Wanderbuch. I. Das obere Ourthal. Aachen, Jgn. Schweitzer. 1891.
[3] Mit fünf Bildern nach Skizzen von Prof. W. Altenburg, einem Tourenverzeichnis und einer Karte. Köln, J. P. Bachem.
II.
Aus Malmedys Vergangenheit.
Malmedy, der Hauptort der preußischen Wallonie, hat bis jetzt keinen deutschen Geschichtsschreiber gefunden. Die Vergangenheit dieser Stadt bietet aber schon deshalb ein besonderes Interesse, weil noch jetzt dort das Wallonische und Französische vorherrschend sind, obschon Stadt und Umgebung bereits seit Anfang dieses Jahrhunderts zu Preußen gehören. Die jetzigen Verhältnisse in Malmedy sind wirklich sehr merkwürdig. Die Bewohner der Stadt und einer Anzahl benachbarter Ortschaften sprechen unter sich wallonisch; viele beherrschen auch die französische Schriftsprache sehr gut. Daneben ist, besonders in den letzten Jahrzehnten, das Deutsche aufgekommen, nachdem diese Sprache in der Volksschule eingeführt wurde. Wir wollen im Nachfolgenden einen kurzen Rückblick auf die Vergangenheit Malmedy’s werfen; es wird uns dann auch manches erklärlich, was uns sonst ein Rätsel bleiben würde.
Malmedy war von jeher mit dem bei Belgien verbliebenen Stavelot (Deutsch: Stablo) ethnographisch und geschichtlich verbunden. Deshalb sind die Beziehungen zwischen beiden Städten trotz der politischen Trennung immer sehr lebhaft geblieben. Die Geschichte Malmedy’s schildern heißt auch die Stavelot’s erzählen, denn beider Geschichte war bis zum Beginn unseres Jahrhunderts eng verbunden. Nur die besonderen Ereignisse in Stavelot, die keine Rückwirkung auf die Abtei ausübten, lasse ich unberücksichtigt.
Zu der nachfolgenden kurzen Geschichte von Malmedy habe ich hauptsächlich die Werke der beiden de Noüe benutzt, besonders:
„Etudes historiques sur l’ancien pays de Stavelot et Malmédy, par Arsène de Noüe, docteur en droit“[4] und „La Législation de l’ancienne principauté de Stavelot-Malmédy, par Paul de Noüe, docteur en droit, référendaire de régence, membre correspondant de l’Académie d’archéologie de Belgique“[5].
Die Abteien Stavelot und Malmedy wurden im 7. Jahrhundert im Ardennerwalde gegründet. In der Gegend hatte der deutsche Stamm der Eburonen gewohnt, der von den Römern unterjocht wurde. Der Teil der Ardennen gehörte zur Germania inferior, die von den Franken besetzt wurde. Die austrasischen Könige betonen in mehreren Urkunden, daß der Ardennerwald ihnen gehörte (in terra nostra silva arduennense). Siegebert ließ eine Anzahl Klöster gründen, worunter auch Malmedy und Stavelot. Er betraute mit der Errichtung derselben den heil. R e m a c l u s , der am Hofe des Königs Dagobert gelebt hatte. Der Apostel der Ardennen, wie er später genannt wurde, verbreitete um die Mitte des 7. Jahrhunderts das Christenthum in Aquitanien. Er baute also mit Unterstützung des Königs Siegebert im Jahre 648 ein Kloster, in welchem Söhne des hl. Benediktus ihren Aufenthalt nahmen. Dasselbe gehörte zum Kölner Sprengel. Von dieser Stiftung Malmundarium oder Malmidarium (a malo mundatum) soll die Stiftung ihren Namen erhalten haben.[6] Als Remaclus Bischof von Tongern (nach andern von Mastricht) wurde und eine eigene Diözese besaß, gefiel es ihm nicht, sein Kloster einem fremden Sprengel einverleibt zu sehen, und er beschloß deshalb, sich einen zweiten Konvent zu gründen, nämlich in dem 1½ Stunden westlich von Malmedy gelegenen, zu seinem Bistum gehörigen Stavelot. Dort entstand bald (gegen 650) eine weitere prächtige Abtei, und von da an blieben die beiden hochangesehenen, mit vielen Vorrechten ausgestatteten Schwesterklöster Stavelot-Malmedy, deren spätere Fürstäbte souveräne Herrscher waren, vereinigt.
Bei der Teilung des Reiches Karls des Großen kam das Land, in welchem die beiden Klöster lagen, mit zu Lothringen, das so lange ein Zankapfel zwischen Frankreich und Deutschland sein sollte. Daß Stavelot und Malmedy bald zu dem einen, bald zu dem andern Lande gehörten, beweisen die Urkunden aus jener Zeit. Beide
Abteien wurden im 10. Jahrhundert unabhängig, ebenso wie die von Trier, Prüm, Echternach u. s. w. Besonders Malmedy lag in einer schönen Gegend, denn der hl. Bernhard sagt: Malmundarium totius Arduennae vallis amoenissima. Man wird wohl nicht irre gehen in der Annahme, daß schon damals die nationalen Gegensätze sich wenigstens in der Nähe von Malmedy bemerkbar machten. Während die Ober- und Niederfranken die Thäler der Mosel, Saar, Sauer, Ur, Ahr, Erft und Ruhr (Roer) besetzten, blieben die Thäler der Amel (Amblève) und Warche im Besitze der zurückgedrängten KeltoRomanen, wo diese noch heute den romanischen Volksstamm der Wallonen bilden. Malmedy und Umgebung wird also schon damals ein Vorposten des späteren Wallonentums gewesen sein.
Die beiden Klöster waren seit ihrer Gründung eng mit einander verbunden und bildeten eine freie fürstliche Abtei. Diese war abgabefrei, hatte aber die Verpflichtung, dem Kaiser Heeresdienste zu leisten. Zwei Punkte in der Geschichte der Abtei sind bemerkenswert, zunächst, daß Stavelot das einzige Kloster war, dessen Oberhaupt Rang und Rechte eines Fürsten hatte und gleichzeitig zum Kriegsdienst verpflichtet war, dann daß der Doppelkonvent, obgleich eines und desselben Ursprungs, zwei verschiedenen Diözesen zugehörig war. Die Einweihung der Kirche und Altäre von Stavelot geschah durch den Bischof von Lüttich, während der Erzbischof von Köln diese Handlungen im Abteibezirk von Malmedy vornahm. Bis zur französischen Revolution hatte jedes Kloster sein eigenes Kapitel, seine eigenen Novizen usw. Beide Kapitel waren gleich und von einander unabhängig. Das zu den Klöstern gehörige Gebiet war gemeinschaftlich, ebenso wie sie nur einen Abt hatten, zu dessen Wahl beide gleichberechtigt waren. Aber schon der hl. Remaclus zog Stavelot vor, wo er auch begraben wurde. Seither mußten auch die Mönche von Malmedy ihre Gelübde am Grabe des Heiligen ablegen. In Stavelot residierte gewöhnlich der Abt und dort hielten die Kapitel ihre Versammlungen ab. Diese Bevorzugung Stavelots wurde in Malmedy nur ungern gesehen und gab zu manchen Differenzen Anlaß, die später sogar zu der Teilung der Güter führte.
Im Uebrigen war das geistliche Fürstentum ein kleines selbständiges Staatswesen, das weltlich nur vom Kaiser und geistlich direkt von Rom abhing. Es vereinigte Jahrhunderte hindurch ein glückliches, draußen in der Welt fast unbekannt gebliebenes Völkchen. Die Benediktinermönche rodeten die Wälder aus und bebauten die Felder. Reich waren sie ursprünglich nicht; dieses bezeugt ausdrücklich Christian Druthmare (840), der mehrere Jahre bei ihnen gelebt hatte. Ihre Klosterschulen zeichneten sich durch berühmte Lehrer aus, wie Druthmare, Notger, Everhelm, Theodorich, Wibald, Zantfliet usw Nicht lange hatte Remaclus seinen Bischofssitz inne; schon im Jahre 660 leistete er auf denselben Verzicht und kehrte nach seiner Abtei zu Stavelot zurück, wo er um das Jahr 669 starb; noch heute werden die Gebeine des heiligen Ordensmannes in der Pfarrkirche daselbst aufbewahrt. Mit dem Tode des Gründers endete aber sein Werk nicht; nicht weniger als 77 Fürstäbte zählt man als Nachfolger des hl. Remaclus, von denen neun heilig gesprochen wurden, während viele andere es in den Wissenschaften und in der Politik zu hohem Ansehen brachten. Die Großen Europas, insbesondere die deutschen Kaiser und Könige, wetteiferten darin, die Fürstäbte von Stavelot-Malmedy mit Ehrenund Gunstbezeugungen auszuzeichnen. Leider ist durch die Verwüstungen, denen die Abteien zu verschiedenen Zeiten unterworfen waren, wohl nicht zum Mindesten durch die französischen Vandalen, die schließlich den Untergang des Fürstentums herbeiführten, sehr viel Material aus den Archiven der Abteien vernichtet oder zerstreut worden.
Die Nachfolger des hl. Remaclus sind nicht alle dem Namen nach bekannt; ihre vollständige Aufzählung wäre auch ohne besonderes Interesse. Mehrere von ihnen gelangten zu hohen Würden, so der hl. A g i l o l f u s , der Erzbischof von Köln wurde. In einer dichterischen Beschreibung des Todes dieses Heiligen wird auch die Schlacht bei Amel (Amblève) im Jahre 716 geschildert, die die Vorläuferin der großen Kämpfe Karl Martells werden sollte. Amel (Amblava) wird als ein Ort im Ardennergau, 2 Meilen von Malmedy entfernt bezeichnet. Der hl. Agilolfus soll dort den Martertod erlitten haben. Die Abtei mußte in der folgenden Zeit manche Widerwärtigkeiten erleben, die die Folgen der Kriegswirren waren.
Im Jahre 877 wurden die beiden Klöster von den Normannen in Brand gesteckt und der Abt H i l d e b a l d mußte mit den Mönchen in die Ardennen flüchten; bei seiner Rückkehr fand er nur mehr Trümmer vor. Als Heinrich der Vogler Lothringen erhielt (zwischen 921 und 924) wurde das Fürstentum Stavelot-Malmedy, das bis dahin die Schicksale Austrasiens und Lothringens getheilt hatte, dem deutschen Reiche einverleibt. Arséne de Noüe hebt in seiner Geschichte ausdrücklich hervor, daß nach dem Anschluß an das deutsche Reich die Abtei Stavelot-Malmedy aufblühte („c’était l’aurore de la restauration qui se levait sur le pays“). Der hl. O d i l o n richtete die Klöster wieder auf, deren bürgerliche und religiöse Verwaltung in Verfall geraten war. Er berief dorthin den berühmten Notker (Notger, Notakar) aus St. Gallen, der später Bischof von Lüttich wurde und das Leben des hl. Remaclus schrieb. Er leitete die Schulen der Abtei, die damals in hohem Ansehen standen. Er predigte in lateinischer und jener romanischen Sprache, die später das Wallonische wurde (Vulgari plebem, clerum sermone latino erudit). Erst der Abt We r i n f r i d ließ die Klosterkirche von Malmedy, welche von den Ungarn nach dem Einfall der Normannen zerstört worden war, wieder aufbauen. Unter seinem Nachfolger R a v e n g è r e wurde sie vollendet und am 10. September 992 vom Erzbischof von Köln geweiht zu Ehren der Heiligen Petrus, Paulus, Johannes, Quirinus und Justus. Der neue Abt ließ in Malmedy, das inzwischen eine Stadt geworden war,[7] die St. Gereons-Pfarrkirche bauen und am 2. November 1007 von dem Erzbischof Heribert weihen. Die von dem hl. Agilolfus gegründete St. Laurentiuskirche, die als gemeinsame Kirche diente, wurde 1661 zur Verschönerung der Abteikirche, an die sie angelehnt war, abgerissen. Später wieder aufgebaut, wurde sie mit der Abteikirche ein Raub der Flammen bei dem großen Brande von 1689.
Der hl. P o p p o , dessen Leben der Mönch und spätere Abt Everhelm aufgezeichnet hat, war einer der größten Aebte des Reichsfürstentums. Er regierte von 1020 bis 1048. Nach dem Tode des Abtes Bertrand hatte Heinrich III. ihn als dessen Nachfolger wählen lassen. Stadt und Kloster Stavelot, die mit dieser Wahl nicht zufrieden waren, lehnten sich gegen ihn auf, und Poppo mußte nach Malmedy flüchten; der Sturm legte sich übrigens bald. Obschon
