If a document of ClassA is changed to ClassB, security group of the document doesn't change i.e. it still has ClassA security group.
I'm trying to understand what could be the reason/benefit/advantage behind this?
I expected the security groups changed to Class but not.
In fact, the Documentation says exactly what you summarized in your question:
You can assign a different class to existing document objects. For
example, you might add a document and assign it a document class of
Manuals because you intend it to be a chapter in an installation
manual. Later, you find the document is better placed in your training
materials and change the document class to Courseware. Later still,
you decide to remove it from the manual and make it a Technical
Notice, which has its own document class of Tech Notes®.
Assigning a different class does not:
Change the security permissions that the original document class directly applied to that document object. You can change the security
by editing the security lists of the document object.
Cause the content of existing document objects to be moved. The default storage area and storage policy of the new document class
apply only to new instances of the class.
You can also browse the existing versions of a document to examine the
history of the class assignments for the document. If your saved
searches use the former document class as a search parameter, you
might no longer find the document.
I think that the main reason has to be found in FileNet approach, that - being it an ECM and not a DBMS - sets a distinction between content and metadata. This brings some observations to my mind:
The ACL for a particular Document Class are defined in their Default Instance Security. As the name implies, these are the security rules set by default when an instance of that class is created. This does not mean that a strict bound between a Document Class and their ACL exists, just that a default setting exists.
Consider the example in the Documentation: a document has been reclassified from Manual to Courseware. This could mean that some operations have been done on that document, before the class' change. If those operations were done by users that have visibility on Manuals, but not on Courseware, it's not right to brutally hide that document to those users.
Generally speaking, separating the CHANGE_CLASS permission from others (as WRITE, DELETE, etc...) adds a bit of freedom to software designers and administrators that use FileNet. Considering the example above again, hiding the document (or changing the permissions), could be necessary in case of a transition like "Public Administration -> Top Secret", but it could not be the case of "Manuals > Courseware".
Related
Here is an interesting problem regarding the IncludeEventHandler.
I am developing a Spring-Based application which uses velocity which has different VENDORS having a separate portfolio site. I am letting vendors customize the pages by providing them the Velocity templates which are being stored the database and are picked up by the velocity engine using a DataSourceResourceLoader.
My table is organized like this.
The vendors may parse other templates by calling the macro #parse and passing their vendorid/template-name so that it looks like this.
#parse("20160109144/common-css.vm")
Now the actual problem is picking up the template according to vendorid.
I have a class (extending IncludeEventHandler) which overrides the includeEvent method. Now what can I do to return the desired template? I dont want to change the names and make them look like 20160109144/home.vm
With OP's question, the intent was to provide an alternate behavior to the DataSourceResourceLoader.
Unfortunately, the Velocity Engine version 1.7 doesn't have ability to change the SQL statement that is used to retrieve the template.
The DataSourceResourceLoader extends the ResourceLoader abstract class. That said, if you reference the source, you should be able to implement a custom ResourceLoader that behaves the way you want it to.
One option, glom most of the code from DataSourceResourceLoader and change the way it determines the template content to load from the database.
I would dump all of the query related material as you will be determining the specific columns you want to load for content. The DataSourceResourceLoader essentially maps the name of a template to a database entry and your implementation essentially revolves around the rules you've defined above.
Hopefully that can provide enough assistance to move forward. I would recommend pulling this in a debugger as well and determine what is and is-not passed in to the related load methods.
I am a total newb to Spring. Even though I understand the concepts of individual annotations (and dependency injection), I am having difficulty "seeing the forest for the trees." Here, in this example, I have a page that has a dropdown box. It also stores the user's selected option from that box. So there are three beans, only one of which is properly called a domain bean:
DropDownEntry *domain
SelectedOption (which could be String or a whole DropDownEntry type stored at Session Scope)
PageModel (containing a List of #1 above, and a single instance of #2)
Below is an image of my best guess as how to use Spring to:
1. Retrieve a List from the persistence layer via DAO
2. Retrieve/Store the user's selection
Is this design remotely near correct? Is there an alternate "best practices" way to architect this scenario?
I think Spring MVC Forms might be what you are looking for.
http://www.javacodegeeks.com/2013/07/spring-mvc-form-handling-vol-5-select-option-options-tags.html
Model
The model is a map of entries for the drop down box.
Controller
You can fetch these entries from a database using the DAO Pattern and turn it into a map in a controller class.
View
The drop down box is generated using a mix of HTML, a JSP tags and map of 'drop-down' entries.
Hard to tell. But from the looks of it, you've made things awfully complicated.
My advice: stop drawing UML, re-read the specification, and start coding. Start with a simple model class that represents the selectable entity. Don't name it DropDownEntry (unless you're creating software to model dropdowns), but something that actually describes the selectable entity. Don't worry about data access (DAOs) at this point.
Then create a controller class that allows you to render a view that contains the said dropdown UI element. Then pass the selectable entities (as reference data) to the view in the model. Then make the view render the selectable entities appropriately. Then allow the user to post the selection back to your controller.
Once you have this, you can think about saving the selected entity to persistent storage. At that point you will probably find out that you need to link the selected entity to a user etc.
Good luck.
I have this idea of generating an array of user-links that will depend on user-roles.
The user can be a student or an admin.
What I have in mind is use a foreach loop to generate a list of links that is only available for certain users.
My problem is, I created a helper class called Navigation, but I am so certain that I MUST NOT hard-code the links in there, instead I want that helper class to just read an object sent from somewhere, and then will return the desired navigation array to a page.
Follow up questions, where do you think should i keep the links that will only be available for students, for admins. Should i just keep them in a text-file?
or if it is possible to create a controller that passes an array of links, for example
a method in nav_controller class -> studentLinks(){} that will send an array of links to the helper class, the the helper class will then send it to the view..
Sorry if I'm quite crazy at explaining. Do you have any related resources?
From your description it seems that you are building some education-related system. It would make sense to create implementation in such way, that you can later expand the project. Seems reasonable to expect addition of "lectors" as a role later.
Then again .. I am not sure how extensive your knowledge about MVC design pattern is.
That said, in this situation I would consider two ways to solve this:
View requests current user's status from model layer and, based on the response, requests additional data. Then view uses either admin or user templates and creates the response.
You can either hardcode the specific navigation items in the templates, from which you build the response, or the lit of available navigation items can be a part of the additional information that you requested from model layer.
The downside for this method is, that every time you need, when you need to add another group, you will have to rewrite some (if not all) view classes.
Wrap the structures from model layer in a containment object (the basis of implementation available in this post), which would let you restrict, what data is returned.
When using this approach, the views aways request all the available information from model layer, but some of it will return null, in which case the template would not be applied. To implement this, the list of available navigation items would have to be provided by model layer.
P.S. As you might have noticed from this description, view is not a template and model is not a class.
It really depends on what you're already using and the scale of your project. If you're using a db - stick it there. If you're using xml/json/yaml/whatever - store it in a file with corresponding format. If you have neither - hardcode it. What I mean - avoid using multiple technologies to store data. Also, if the links won't be updated frequently and the users won't be able to customize them I'd hardcode them. There's no point in creating something very complex for the sake of dynamics if the app will be mostly static.
Note that this question doesn't quite fit in stackoverflow. programmers.stackexchange.com would probably be a better fit
We're looking for a way to document Core Data entities. So far the only real options I've come up with are:
Document externally using UML or some other standard
Create NSManagedObject subclasses for every entity and use code comments
Use the User Info dictionary to create a key value pair that holds a string comment
Option 1 feels like too much extra work and something that will almost certainly be out of date 99% of the time.
Option 2 feels natural and more correct than option 1. The biggest con here is that those comments could potentially be lost if this model class is regenerated using Xcode.
Option 3 feels a little less correct than option 2, but has the added advantage of adding automation possibilities with regards to meta data extraction. For instance, in one of our apps we need to keep a real close eye on what we're storing locally on the device as well as syncing to iCloud. Using the user info dictionary it's pretty easy to automate the creation of some form of artefact which can be checked both internally and externally (by the client) for compliance
So my question is whether it would be inappropriate to use the user info dictionary for this purpose? And are there any other options I'm missing?
Option 2 is what I use every time. If you look at your core data model (something.xcdatamodeld or something.xcdatamodel) you will see something like the picture below.
You can tie your entity to whatever class you want and then put the comments in there. It helps if you keep your entity name the same as your class name to make it obvious what you've done.
Additionally this also gives you the ability to add automation. You can do this by creating custom getters and setters (accessor methods) and a custom description method.
I use option 2 and categories. I'll let XCode generate the NSManagedObject subclasses and use a categorie on each of these subclasses. With the categories I do not loose my changes made in the categories, can document, make custom getter and setters and I am still able to use generated subclasses.
If we speak only about documenting (i.e. writing more or less large amounts of text which is intended to be read by humans) your classes, I'd use the option 2.
If you are concerned with the possibility of Xcode overwriting your classes in the option 2, you may consider creating two classes for each entity: one which is generated by Xcode and always could be replaced (you generally do not touch this file) and one other which inherits from the generated one and in which you put all your customizations and comments.
This two-class approach is proposed by the mogenerator.
Although if you need to store some metadata with the entities which will be processed programmatically, the userInfo is perfectly suitable for this.
I'm a little confused about calls I see to Mage::getSingleton, and I'm hoping someone can help me understand a little better.
I have seen a piece of core code that does this:
Mage::getSingleton('customer/session')->isLoggedIn()
I don't know PHP, but I think I can make a safe assumption from the getSingleton method name that there will be only one instance of the class specified (the class being specified as a grouped class name, and resolving to app/code/core/Mage/Customer/Model/Session.php - containing class Mage_Customer_Model_Session.
Question 1 -
How did the getSingleton method know to look in the Model folder for the class?
Question 2 -
So there is one instance of the class for the whole ... I want to say JVM as I am from a Java background, but I'll say PHP engine in the hope that that is vaguely the correct terminology; the Mage_Customer_Model_Session is not passed in a customer id or any such identifier, yet we call the method isLoggedIn()! Give there is not a Mage_Customer_Model_Session instance per customer, how can we ask a singleton if a customer is logged in when we do not tell it what customer we are talking about?
Question 3 -
I've seen calls to Mage::getSingleton('core/session') and to Mage::getSingleton('customer/session') - what is the difference?
Thank you for any help.
First, before we get to Magento, it's important to understand that PHP has a radically different process model than Java. A PHP singleton (regardless of Magento's involvement) is a single instance of a class per HTTP Request. A PHP program isn't persistent in memory the same way a Java program is, so adjust your expectations of a "singleton" accordingly.
Next, it's important to understand that Magento is a framework built on top of PHP, using PHP, and in many cases the original Magento developers wanted to push things towards a more Java like architecture. So, you're going to see things that look familiar, are familiar, but likely differ in some major way from what you're used to because they still need to hew to PHP's version of the universe.
Magento uses a factory pattern to instantiate Helpers, Blocks, and "Model" classes. The string
core/session
is a class alias. This alias is used to lookup a class name in Magento's configuration. In short, this string is converted into path expressions that search Magento's configuration files to derive a classname, based on the context (helper, block, model) it was called in. For a longer version, see my Magento's Class Instantiation Autoload article.
The concept of a "Model" is a little fuzzy in Magento. In some cases models are used as domain, or service models. In other cases they're used as a more traditional middleware database persistence models. After working with the system for a few years, I think the safest way to think about Models is they're Magento's attempt to do away with direct class instantiation.
There's two ways to instantiate a model class.
Mage::getModel('groupname/classname');
Mage::getSingleton('groupname/classname');
The first form will get you a new class instance. The second form will get you a singleton class instance. This particular Magento abstraction allows you to create a singleton out of any Magento model class, but only if you stick to Magento's instantiation methods. That is, if you call
Mage::getSingleton('groupname/classname');
then subsequent calls to
Mage::getSingleton('groupname/classname');
will return that singleton instance. (This is implemented with a registry pattern). However, there's nothing stopping you from directly instantiating a new instance of the class with either
$o = Mage::getModel('groupname/classname');
$o = new Mage_Groupname_Model_Classname();
Which brings us to sessions. PHP's request model, like HTTP, was originally designed to be stateless. Each request comes into the system with, and only with, information from the user. As the language (and the web) moved towards being an application platform, a system that allowed information to be persisted was introduced to replace the homegrown systems that were cropping up. This system was called sessions. PHP sessions work by exposing a super global $_SESSION array to the end-user-programmer that allow information to be stored on a per web-user basis. Sessions are implemented by setting a unique ID as a cookie on the user end, and then using that cookie as a lookup key (also standard practice for web applications)
In turn, the Magento system builds an abstraction on top of PHP's session abstraction. In Magento, you can create a "session model" that inherits from a base session class, set data members on it, and save/load those data members just as you would with a database persistence model. The difference is information is stored in the session instead of the database store. When you see
core/session
customer/session
these are two different session models, with each one storing different data. One belongs to the Mage_Core module, the other belongs to the Mage_Customer model. This systems allows modules to safely set and manipulate their own session data, without accidentally stepping on another module's toes, and provide logical class methods for manipulating that data.
Hopefully that answers the questions you asked, as well as the ones you didn't.
Magento's getSingleton is almost the same as getModel. The difference is getModel always returns a new instance of a class, and getSingleton creates a new instance of a class only once and then always returns this instance. See the Mage::getSingleton and Mage::getModel methods.
Magento knows about looking to the Model folder because of configs in the config.xml file (f.e. Mage/Customer/etc/config.xml). See the Magento wiki for developers to know more about config files.
You do not specify customer directly. It's done automatically by Magento in parent classes of Mage_Customer_Model_Session (see Mage_Core_Model_Session_Abstract_Varien::start() method)
Magento has not one session class to discriminate session data. For example, customer ID is stored in Mage_Customer_Model_Session and error flash message 'Product is not available' will be stored in the Mage_Catalog_Model_Session class.