i am trying to extend alfresco's document management by running a script. So far, i have managed to create a Custom Model with a Custom Type and Property as seen below:
the said Custom Type is under this Custom Model (never mind the Custom Aspect for now)
the custom type is working so far, i managed to apply it to a certain document as you can see below (Notice the Control Code Field)
now what i want to do is to add an auto incrementing function that will be set as the value of the Control Code Property (ie: [FILE0012])
i tried utilizing the scripts rule from alfresco but it seems like the commands are limited to that of alfresco's functionalities. not even alert() or console.log functions work. i thought that if i can make a script that could call an ajax to my php server, i can extract the document's property, and insert it to my database and get the rowid then attach it to a word "FILE" so it becomes the Control Code Property (ie: a document was inserted to my database at row 1996, then the Control code is [FILE1996], this is because i joined '[FILE' and 1996 and ']'
but like i said, what happened was, the javascript commands are limited to that of alfresco's needs.
i tried to make my research but i've only bumped on 2 outdated (and i mean outdated) threads dating back to 2006-2010. which does not help me quite well with Alfresco's current build structure.
i hope someone can help me with here. connecting to the database is not mandatory, but if i can make it do as such then it'll give me quite a rather amazing results.
Take a look at the "cm:countable" aspect. You do not have uniqueness guaranteed OOTB, so take that into account.
Example:
http://www.avantec.se/howto-create-an-auto-increment-field-on-an-object-in-alfresco/
Related
What would be a proper way to handle global "settings" in my sailsjs application? The user will want to change those settings via the web front of my app.
I imagine I could use a new model "GlobalSettings" with only one item, but I don't really know if it's a good "MVC" practice.
Since it is based on user input, it has to be stored in a database and therefore storing it in model seems like a right choice to me.
Having just 1 row/collection is completely ok in my opinion, especially in the no-SQL field. But for more reusability and scalability, you might want to consider to actually store each setting in invididual row, that might give you space to expand the usability of it in the future.
In my own opinion, I always find as a web app develops, you will start to realize there are more and more fields that you want the user to setup as their preference, as a good practice to relax the application.
For me I usually setup a meta_data model with name, value, criteria, and some other fields.
For example, when viewing your web page, 'Alice' may want a background color of black, 'Bob' may want a background color of green. Then you can let them modify or insert row into this meta_data collection. Then in your database, you will have
name value criteria
background_color black user_name='Alice'
background_color green user_name='Bob'
and it can be all kinds of values.
of course if you just have one value that can be changed by all of your users, it is probably a good idea to know who updated them. For this you would want to create a trigger, (if you are using a sql database)see trigger in mysql, so that every update on the table will trigger a function that stores what was changed and who changed it in another table
So yes, to answer your question, it is totally ok to have a model to store a value, and don't worry about only have one row, you will have more as you develop your app.
The config/globals.js file seems to be a good place to place a global configuration setting.
For convenience, Sails exposes a handful of global variables. By
default, your app's models, services, and the global sails object are
all available on the global scope; meaning you can refer to them by
name anywhere in your backend code (as long as Sails has been loaded).
Nothing in Sails core relies on these global variables - each and
every global exposed in Sails may be disabled in sails.config.globals
(conventionally configured in config/globals.js.)
Sailsjs.org Documentation - Globals
Alternatively you can use the sails.config object.
Custom Configuration
Sails recognizes many different settings, namespaced under different top level keys (e.g. sails.config.sockets and
sails.config.blueprints). However you can also use sails.config for
your own custom configuration (e.g.
sails.config.someProprietaryAPI.secret).
From the docs
There is also services which is global by default.
Overview
Services can be thought of as libraries which contain functions that you might want to use in many places of your application. For example,
you might have an EmailService which wraps some default email message
boilerplate code that you would want to use in many parts of your
application. The main benefit of using services in Sails is that they
are globalized--you don't have to use require() to access them.
It really depends on what kind of global you are wanting.
We have a requirement to allow customising our core product and adding additional fields on a per client basis e.g. People entity some client wants to record their favourite colour etc. As far as I know we can't add properties to EF at runtime as it needs classes defined at startup. Each customer has their own database but we are deploying the same solution to all customers with all additional code. We are then detecting which customer they are and running customer specific services etc.
Now the last thing I want is to be forking my project or alternatively adding all fields for all clients. This would seem likely to become a nightmare. Also more often than not the extra fields would only be required in a very limited amount of place. Maybe some reports, couple of screens etc.
I found this article from Jermey Miller http://codebetter.com/jeremymiller/2010/02/16/our-extension-properties-story/ describing how they are adding extension properties and having them go from domain to the web front end.
Has anyone else implemented anything similar using EF? How did it work out? Are there any blogs/samples that anyone has seen? I am not sure if I am searching for the right thing even if someone could tell me the generic name for what we want to do that would help. I'm guessing it is a problem that comes up for other people.
Linked question still requires some forking or implementing all possible extensions in single solution because you are still creating strongly typed extensions upfront (= you know upfront what extensions customer wants). It is not generally extensible solution. If you want generic extensible solution you must leave strongly typed world and describe extensions as data.
You will need to use some metamodel. Your entity classes will contain only properties used by all customers and navigation property to special extension entity (additional table per every extensible entity) where you will be able to put additional properties as name / value pair (you can add other columns like type, validation, etc. if needed).
This will in general moves part of your model from hardcoded scenario to configuration based scenario and your customers will even be allowed to define extensions at runtime (if you implement such feature).
Is there a list somewhere that lays out all of the types of changes that can be made to an existing workflow service that would prevent existing instances of the original workflow from being re-loaded? For example, I recently made a small change to a custom activity (changed a condition in an "if" statement) and all existing workflow instances still load as normal. Now, in the past, I had removed a property on an object that the workflow uses, and when I tried to re-load a persisted workflow instance, it blew up on me.
Does such a list exist? Thanks!
As far as I am aware there isn't a list like that. You really should consider all changes as breaking. If you test thoroughly you will find a few exceptions but these will be mostly changing a single VB expression.
There is no such a list.
As far as I am concerned, you can change VB expressions always editing the .xamlx in a text editor. I say that, because in my case, sometimes the graphical editor (VS2010) changed the ids of the activities without introducing new activities (be carefull with this).
You can also change the whole internal code (not the inputs/outputs parameters) in code activities (.xaml). Because of that, it would be a good idea to put all the "high changeable" logic into code activities in order to be able to modify this logic avoiding problems with existing WF instances.
I am developing a site that is saving non visible user data upon login (e.g. external ID on another site). We are going to create/save this data as soon as the account is created.
I could see us saving data using
the content profile module (already in use on our side)
the profile module
the data column in the user table
creating our own table
I feel like #1 is probably the most logical place, however creating a node within a module does not seem to be a trivial thing.
#3 feels like a typical way to solve this, but just having a bunch of serialized data in a catchall field does not feel like the best design.
Any suggestions?
IMO, each option has its pro's and con's, and you should be the one to make the final call, given that you are the only one to know what your project is about, what are the critical points of the project, what is the expected typical user pattern, what are the resources available, etc...
If I was totally free to chose, my personal favourites would be option #4, #1 and #5 (wait! #5? Yes: see below!). My guiding principles in making the choice would be:
Keep it clean
Keep it simple
Make it extensible
#1 - The content profile module
This would be a clean solution in that you would make easier for developer to maintain your code, as all the alteration to the user would pass through the same channel, and it would be easier to track down problems or add new functionality.
I do not find it particularly simple as it requires you to interact with the custom API of that module.
As for extensibility that depends from how well the content profile module API is designed. The temptation could be to simply use the tables done by said module for your purpose, bypassing the API's but that exposes you to the possibility that on a critical security update one day in which you are in a hurry the entire system will break down because the schema has changed...
#4 - Creating your own table
This would be a clean solution because you could design your table (and your module to do exactly what you need to), and you could create your own API to be used by other modules. On the other hand you would introduce yet another piece of code altering the registration process, and this might make it more difficult for devs to track problems and expand the system in a consistent way.
This would be very simple to implement code-wise. Also the DB design would benefit though: another thing to consider is that the tables would be very easy to inspect and query. Creating a new handler for views is dead easy in most of the cases: 4 out of 5 you simply use one of the prototype objects shipping with views.
This would be extremely easy to extend, of course. Once you created the module for one field, you could manage as many as you want by mostly copy/pasting the code for one field to another (or to inherit from the same ancestor if you go OOP).
I understand you are already knowledgeable about drupal, but if you need a pointer on how to do that, I gave some direction in this other answer.
#5 - Creating your own table and porting already existing fields there
That would essentailly be #4 minus the drawback of scattering functionality across various modules... Of course if you are already managing 200 fields the other way this is not a viable option, but if you are early into your design, you could consider this.
In my experience nearly every project that requires system integration (meaning: synchronising data for the same user in multiple systems) has custom needs for user registration, and I found this solution the one that suits my need best for two reasons:
I found I reuse a lot of the custom code I wrote from project to project.
It's the most flexible way to integrate data with the other system (in some case I even split data for the user in two custom tables managed by the same module: one that contains custom fields used by drupal only and one that contains the "non visible fields", as you call them. I find this very handy in a lot of scenarios, as it makes very easy to inspect and manipulate the data of the two systems separately.
HTH!
If you're already using the Content Profile module, then I'd really suggest continuing to use it and attach the field to it. You're saving the data when the account is created, and creating a node for the user at the same time isn't that hard. Really.
$node = new stdClass();
$node->title = $user->name; // what I'd use, or you can have node auto title handle the title for you. Up to you!
$node->field_hidden_field[0]['value'] = '$*#$f82hff';
$node->uid = $user->uid;
node_save($node);
Bob's your uncle!
I would go for option 3. Eventually even other modules will store the data in the database against a user. So you could directly save it yourself probably in a more efficient way than those modules.
Of course depending on the size of the data, you can take a call whether to add a new column in the users table or to create a new table for your data with the user's id as the foreign key.
I have a database I'd like to create an entity from, and then generate RESTful output.
My objective is to add a property to one of the tables once it becomes an entity. The data for that property would be one I'd come up with through calculations done on a few different fields in the table. From there, the code generator would create RESTful output like it normally does.
I have managed to be able to update the SSDL, CSDL, and the mapping sections of the edmx file along with using the SampleEdmxCodeGenerator as a custom tool. When I have all the sections in the edmx file filled out with my custom property, the svc fails because (I'm assuming) the property doesn't exist in the database. If I leave the property out of the SSDL, but put it in the client schema (CSDL) and the mapping section, I can't build my project.
I've modified the partial class and added to it, but the problem there is that I need to populate the methods on the creation time of the class, and I haven't been able to do that yet.
Am I headed in the right direction, or is this not possible? It seems like I should be able to do this with minimal effort, but I keep hitting walls.
I think you're taking detours to get where you want. I haven't used either of these approaches (recently), so they might not do exactly what you're after, but you could try this:
Create a partial class file right next to the .edmx model, which has the same name as your entity.
In it, specify the property you want as a read-only property, that does the calculations on each get.
Partial Classes and Partial methods were the first part of my answer. What I'm essentially trying to do I can't do. I can manipulate data that is returned by using partial methods and partial classes. I can plug the OnmethodnameChanged() method to format the data how I'd like it to be shown, but that only gets me part way to my desired result.
What I would also like to do, is create a property c, which doesn't exist as a column in the database (and therefore does not exist in my entity), calculated from a couple different properties in the database (say a and b), and then add property c to the entity framework class. In doing this, I figured it would then get generated into the RESTful webservice output.
A problem that occurs comes from the need for the class to update any changes you make, and have it propagate back to the data source. I didn't care about that, because I want my property to be read only. From what I've gathered this isn't possible.
For reference, these two posts really helped:
Adding custom property to Entity Framework class
(I can only post one url currently, so here is the address to the other article)
social.msdn.microsoft.com/Forums/en-US/adodotnetdataservices/thread/b7a9e01d-c5c2-4478-8f01-00f7f6e0f75f
What I've decided to do, is to expose my entity as I've done so far, then consume the RESTful service that manipulates data and reformats it, and introduces needed properties. I'll turn the results into my own data object, and use that as a datasource to be exposed by yet another RESTful web service. I think this website gives a good example on how to expose a custom datasource.
mstecharchitect.blogspot.com/2008/12/surfacing-custom-data-source-in-adonet.html
If for some reason that is too slow, I suppose I could just make another table in my database that has a reworking of the data, and the calculated output in a format I'm looking for. The thing I want to avoid is having my resulting client having to do any of the data manipulation since it will be on some micro devices like palms, iphones, and blackberries.
Hope that helps anyone else with the same problem. It seems that is a shortfall in the current version of Data Services, but to some extent, I'm sure they'll be addressing it in later versions. Maybe T4 and .net 4.0 will be addressing it. I'm not sure.