I'm trying to find a free replacement for Sharepoint 2010. Particularly I need custom lists creation functionality. I've read that Alfresco is a good replacement, but I can't seem to find any tutorial about custom data list creation. In Sharepoint you can create custom lists and fields out of the box, but it seems that with Alfresco you have to deal with XML code, which is not very user friendly, am I right?
If this is the case, is there any other kind of ECM with this functionality?
Thanks,
With Alfresco, there are (3rd Party) tools providing functionality to model content with a gui at runtime, shielding users from ugly XML. Head over to http://addons.alfresco.com and search for "model". Alfresco Form-Model Management is one example.
That said, I can hardly imagine gui based content modeling qualifiying as a critical feature for the choice of an ECM as usually, developers do it infrequently (in one particular project).
Here is a tutorial that shows how to do custom data lists in Alfresco: http://ecmarchitect.com/archives/2010/04/25/1156. I wrote it against Alfresco 3.3 and haven't tested it against the newest versions, but the content modeling stuff and most Share form config stuff haven't really changed that much since then so give it a shot.
The concept of what ECM is about is evolving rapidly. As someone who's built and managed SharePoint, Documentum, Wiki farms as well as ECM services, Web services, Data services and more in large environments, traditional Web ECM definitions are not what many companies are looking for now in solutions. The Web solution does more than "pure ECM". They are also not built and managed by developers and admins in many cases as well. "User admins" is becoming the norm. SharePoint's hierarchical delegation model and customization capabilities are not an end state but they are headed in the right direction. I'm guessing newer releases of Alfresco may move in this direction as well.
Related
A very good evening to Everyone. I am a frontend 3D developer well versed with Python and JavaScript. Recently I created a frontend application for interior designing based on webgl. I now want to invest my time in making it a SAAS application using Django. Well my experience with Django is minimal with only experience doing a to-do list based on a tutorial, lol. The frontend of the app is only part (~30%) of the final goal. The product is aimed at manufactures and freelancers in interior designing and should use subscription model. Based on the subscription plans the abilities vary. The main vision is to help manufactures in handling projects with designers both in-house and by employing freelancers.
Technically this translates to user types who are 1) individuals, 2) groups, and 3) subgroups. Also there are assets(meshes, textures) that are available as private and public access. One possibility in the roadmap is including the ability of groups to be able to White label the app (custom domain, Logo etc). Finally, the last part of the vision is social media and I am planning to use LinkedIn for this purpose.
Coming to my experience with Django is quite minimal but I was able to understand the fundamentals in having apps, models etc. My question can be summarised to a list of requirements,
1- groups, subgroups, individuals
2- subscription plans and setting limits
3- subdomain and white labeling.
Now, is it better off to write from scratch? Or use some existing Django based apps and integrate to the whole pipeline? Should I use a CMS or CRM? Can you all please guide me with your wisdom.
Also my sincere apologies on my post exhibiting anything ignorant, if any. For it wouldn't have been intentional. Many thanks in advance.
Regards,
0K
I want to make a REST services based application and I have no ideas to start with. Do you have any suggestions?
I know what REST services are and how to implement them, but I don't have an idea for what application to do.
Probably the most standard REST example or case study is a content management system. ie a system where the main resources are "documents" (/documents/1 /documents/2 etc). It could also be "posts" for a blog or "tweets" etc.
You can then enhance it with a separate resource for authors, add policies for reading and writing posts, and so on.
The good thing about this model is there's no real business logic or API scraping to implement, and it's easy to test by checking document contents.
Of course, the best projects to use, when you have the luxury of choosing them, are always those you have a passion for developing.
We are currently on Kentico EMS V.7 but when our site(s) was created there was not any mobile device layouts setup. an out entire site is build around ASPX+Portal templates so we don't have the edit layout option on our pages. What would you recommend an origination like ours do in this case? Is there an import or migration tool that can be used to move the pages into a responsive design template (are these available out of the box or do they all need to be built?)
has anyone else come against this challenge with their site when trying to a mobile accessible site, if so what approach did you take to move your site(s) over?
I know Stackoverflow doesn't like to answer broad questions, but I'll save you some trouble and hopefully at least point you in the right direction. I use to be in your shoes and I remember how frustrating it was trying to find resources to learn all of this.
You've got some options, but unfortunately none of them are magic bullets. All of these options involve design and development time. If you haven't already done the research to consider if optimizing your site for mobile users is a good business decision, then I would suggest starting there first.
Mobile Device Detection
Kentico offers device layouts that allow you to change the layout of your site depending on which device a user is browsing your site with. The technique it uses is called device detection, which relies on reading the incoming user agent string of the user's http request on your server and using that information to determine what to send back to the user's browser.
This process happens on the server side of your application and also relies on comparing the user agent string against a list of known user agent strings. Kentico in particular uses the 51degrees library to accomplish this. This has the drawback of not always having the most up-to-date user agent strings, so new devices won't be included in your list unless you keep it updated.
A big problem with this approach is that you wind up maintaining multiple sites and/or layouts. If you uses Kentico's mobile device detection, then any time you need to make changes to a page template you will also have to change each of the different layouts for that template.
You don't have to utilize Kentico's device layouts functionality to do mobile device detection. You could just redirect users to a different site entirely. In which case you can still very easily run into the problem of redundant maintenance.
Yes, there are ways of mitigating these issues, but most web devs agree that responsive design is usually the way to go if you want to cater to mobile users.
Responsive Design
This is a client-side design paradigm that relies on CSS media queries. I'm not going to explain how it works since googling "responsive design" will net you plenty of research material. The short version is your user's browser handles the adjustment of the layout by interpreting the CSS of your site. This means you maintain one CSS file for one site and the client handles the adjustments for you.
Now the down side to this is that it takes a takes a talented web designer to do it properly. There are many responsive frameworks out there that can help you out with this, but their appearance is pretty generic and will likely still require customization to fit your particular brand requirements. Some more popular ones are bootstrap, semantic-ui, and foundation.
I recently helped convert a large website in Kentico with a static design into a responsive design by rebuilding all of the page templates using Bootstrap and merging their stylesheets together so that the desktop version still looked the same and the mobile versions had a consistent appearance with the desktop version. This process took about two months and required a lot of UX and content strategy in addition to visual design and coding skills to accomplish correctly. It's not the hardest job in the world, but requires quite a bit of skill and time to do.
In my humble opinion there is no tool which will make (magically) your site responsive. AFAIK the only way is to redesign your site manually (new CSSs - maybe any UI framework, JS etc...)
Maybe you can still use out of the box features like device profiles and mobile pages. (But I am not sure how it works and if it is supported while using ASPX + Portal templates development models).
I am planning to use open source gamification - rails based Gioco gem to for enteprise productivity and collaboration applications. I am starting with Sharepoint. While I have supporting material for gamification strategies and use of commercial software apps such as Badgeville, how can I integrate using REST/JSON API with Sharepoint?
Ideally I am looking to generate points on the gamification when users tag, upload, comment on Sharepoint and Yammer. So user action should trigger the REST API.
RedCritter has pre-built integration with SP2013 which is very easy to deploy. There are also pre-built integrations for workflow management tools like Nintex to reward granular behaviors within SharePoint.
https://redcritterconnecter.com/solutions
This is going to be tough. There are far too many places in SharePoint you'd have to handle. While SharePoint does have various event handlers which you can hook up to trigger your code, they would have to be installed farm-wide in all sites, all lists and document libraries, independently. Then you would have to somehow hook up various web parts.
Alternate strategies:
try to handle everything client-side in JavaScript — tedious in nature, error-prone, can't catch everything (e.g. Office integration beyond reach)
turn on auditing everywhere and generate info from audit logs — will be behind in time in respect to user actions, won't catch everything again (e.g. various user interface operations that don't trigger audit records)
In any case, your SharePoint farm admin won't fall in love with this. Most likely you will cause them a lot of troubles and headaches, not speaking about unwanted interferences with 3rd party solutions deployed on the farm.
My recommendation: don't waste your time, it's not worth it.
I would have to agree with Ondrej - SharePoint is fully of proprietary functionality that will be a challenge to work with. I know you had your heart set on going open source, but I know that Badgeville specifically has a SharePoint connector which might get you what you need.
http://badgeville.com/products/integration-catalog/badgeville-for-sharepoint
I want to write a .NET application that will interface in realtime with Dynamics NAV 2009 and 2013. The application will have to read and update entities such as customers and stock items.
Using the provided webservices seem to be the best candidate as a point for integration, and I've tried some basic tests reading, updating and creating items using webservices based on Pages and a .net client.
Unfortunately, I am very new to Dynamics, and I have some questions that probably reflect that lack of experience.
First - webservices can expose either Page or Codeunits. Is Page the correct option to use for interfacing to say - create a customer?
Secondly - My understanding is that Dynamics NAV is rarely deployed without customisation. Would a typical customisation in NAV e.g an addition of a field involve changing a standard Page, and will this change then be reflected in the webservice definition?
You are right - given your requirements, webservices are probably the best option for interfacing with NAV.
Regarding your first question: page web services know how to handle concurrency, and, thanks to the way Visual Studio encapsulates them, expose rich types that you can interact with from your .NET code. All the basic CRUD operations can be carried out using the exposed methods. For a more detailed comparison between codeunit web services and page web services, please refer to http://msdn.microsoft.com/en-us/library/dd355398.aspx.
I think most developers choose not to publish the normal pages (the ones aimed at the NAV Windows Client; previously known as the Role Tailored Client), but instead, create separate, tweaked pages for publishing as a web service. But, if you prefer, I guess you could add your custom field to the standard page and publish that as a web service.
Hope this helps! Good luck! :)