I am currently investigating the possibilities of different CMSs for a company-site. Done quite a few projects in classical ASP, ASP.NET, Joomla etc..
I would like to use Umbraco or Orchard for the first time.
For that project we have a SQL-Table with Departmenst and a second with Job-Opportunities: like: JobName, DepartmentID, Description, etc..
So a 1:n relationship.
A first page should list Departments with links to sub-pages of Jobs available
These should be listed on a second page.
In ASP.NET I would use something like a Repeater, etc.. with PageSize option and automatic paging.
In the Backend (Backoffice in Umbraco, I assume) there has to be an Insert/Edit/Delete Page with the corresponding input boxes, which are maintained by the company employees, not by web-developers.
So in both cms I try to accomplish an Access-like table-form in the backend like:
Job | Description | ....
Job1 | descr1 | ....[edit][delete]
Job2 | descr2 | ....[edit][delete]
Job3 | descr3 | ....[edit][delete]
[New Job]
Which route should I look at? I am completely stuck, is there an example anywhere? Can I use my own data-tables, or could/should I use the built-in content tables for this?
Thank you, Reinhard
This sounds relatively straightforward, in Umbraco anyway, you could use either the built-in content tables, or else use straight SQL server tables and write the code to 'talk' to the db yourself.
The benefit of using the content tables in Umbraco however, is that everything else will be easier to do; everything else in the system is designed to just use those content tables with no extra coding...unless you have a tremendous amount of data, or some special requirements you haven't mentioned, I would definitely fully explore the possibility of just using the built in Umbraco functionality for this, before deciding to roll-your-own custom tables within umbraco.
Its possible, and not that hard, but is is extra work that you shouldn't do unless necessary.
Not familiar with Orchard, so can't comment on that.
Related
I'm making a RoR app that is going to have a bunch of network diagnostic tools in it, like ping, traceroute, whois, etc. It's an internal company thing. Being that I'm learning Rails, I'd like to create it in that.
So, I'm curious what's the best structure to make this? Would it make sense to have all the tools under one MVC, like 'tools', or to break each one out into their own MVC (i.e., ping_controller & model/ping, traceroute_controller & `model/traceroute', etc.)?
So:
App
|--models
| |--tools (which would just write the `ip`, `tool_type` and `hitcount` to the DB.)
|
|--controllers
| |--tools (which would contain the methods: `ping`, `traceroute`, etc.)
|
|--views
|--tools
|--index.html.erb (which would have the individual form to run a given tool and show results)
Or would it make more sense to break it out more, but still keep the individual tool form elements on the same page and direct them with something like form_for(controller: 'ping', action: 'show'):
App
|--models
| |--ping (which would just write the `ip` and `hitcount` to the DB.)
| |--traceroute (which would just write the `ip` and `hitcount` to the DB.)
|
|--controllers
| |--ping (which would contain the normal CRUD and results)
| |--traceroute (which would contain the normal CRUD and results)
|
|--views
|--tools
|--index.html.erb (which would have the individual form to run a given tool and show results)
What's the "Ruby Way" to do this? I feel like the second option is not very DRY, but I'm still learning... hence my question.
If type is the only difference between each types of tools, I would suggest you to use the first way. If there will be more complex logic/columns differences, I would suggest you to have a look into Single Table Inheritance (STI):
http://samurails.com/tutorial/single-table-inheritance-with-rails-4-part-1/
I want to search in content and I don't want to get fault result.
assume users search 'br' I don't want to see in output results that have <br> or <P> and other html elements
Simply, you must strip the tags before you search. However, that would mean not being able to query the database directly. Rather, you'd have to pull all the objects first, and then query the collection in memory.
If you're going to be doing a lot of this or have large collections of objects (where pulling all of them for the initial query would be a performance drag), then you should look into a true search solution. I've been working with Elasticsearch, which seems to be just about the best out there in my opinion. It's easy to set up, easy to use, and has third-party .NET integration through the nuget package, NEST.
With a true search solution, you can index your content fields, stripped of HTML, and then run your queries on the index instead of directly on your database. You'll also get powerful advanced features such as faceting, which would be difficult or impossible to do directly with Entity Framework.
Alternatively, if you can't go full board on the search and it's unacceptable to query everything up front (which really it pretty much always is), then your only other option is to create another companion field for each HTML content property, and always save a HTML-stripped copy of the text there. Then, use that field for your search queries.
What's the best way to do joins in Meteor/mongo? Use one of these packages, or something else:
publish-with-relations
https://github.com/erundook/meteor-publish-with-relations/blob/master/publish_with_relations.coffee
collection-helpers
https://github.com/dburles/meteor-collection-helpers
I'm very familiar with PWR, but collection-helpers is new to me. It looks like the two are complimentary.
PWR solves the somewhat complex problem of publishing documents to the client via a reactive join based on arbitrarily complex relationships. See this question for more details.
collection-helpers appears to be a set of convenience functions added to the client to be used when traversing collection relationships inside of a template (given that the required documents have already been published). For example, if you have books and authors in separate (but related) collections, you can immediately get myBook.author.fullName inside of a template without having to type out the extra find for the author.
currently the top popular solution in atmosphere seems to be publish-composite https://atmospherejs.com/reywood/publish-composite
I am in the process of building a super simple CMS to handle smaller "static" page type projects (e.g. - small sites for friends). I have different "page types" that I would like to add. I built something similar in Coldfusion previously. Looked something like this:
table content_type:
content_type_code varchar(10)
content_type_name
table content:
content_id
content_type_code varchar(10)
content_name
content_desc
content_url
I would create a content type called "blog" or "photo" and each time a content was added, it'd get assigned the content_type_code. Then in /blog/ I'd query for all content that had a content_type_code of "blog".
Now that I'm using Ruby/RoR I am trying to think about things differently. I was thinking a better way might be to use nested pages with awesome_nested_set (https://github.com/collectiveidea/awesome_nested_set). But I'm not sure if that's the best solution.
Then I could create a page called "blog" and add to that many pages. So essentially the top level would take place of the "content_type" from my previous example.
Can someone steer me in the right direction on what the best method would be? I'm a newb looking for a kick in the right direction.
EDIT
I should add that the only real thing that I would change between the different "types" of content would be the layout and where they are displayed ("photo" content at /photos/, "blog" content at /blog/).
I try to recap:
You want to build a CMS
Your CMS manages a single web site
A web site is made of content
There are differenti type of contents, and I am assuming every type of content has its own behaviour
Contents are organized in a tree
Here is the plan I suggest you:
Create the Content resource; use the scaffold to have something already working, adding few field (title and body in example)
Add validations to your new model
Write a couple of unit tests against your validation (quite useless, just to see how it works)
Install awesome_nested_set and manage to make it working with your model
Work on the UI to make it quite easy to create new content, move content around, edit a single content
Now its time to implement the content types; STI is the Rails way, but I have to warn you it can be really hard. I suggest you to reiterate 1, 2, 3, 5 to create new models for Photo and BlogPost
Once you will be there, you will have hundreds of ideas to implement. Have fun :)
Instead of using content_type I would rather let the user choose a model on a selection page, like "photo" or "blog" and load an editing page based on that selection. So the user wants a new 'blog'-entry they get redirected to blog/new or 'photo' for photo/new. It's the easiest way to go in terms of usability and your controlling backend and you don't have redundant data (for example an empty photo url which is not necessary in a blog-type) in your database.
Ever wonder what wikipedia's database schema looks like? I recently read this thread from reddit.
I like how their tables are tagged with a prefix so you can sort of tell its functionality, purpose, and relationship with other tables right off the bat.
One thing I do not notice is how they name their stored procedures. Do they even use SP?
I use MS SQL Server. Prefixing all stored procedures with USP_ or SP_ seems redundant and anti-beneficial as the object explorer already sorts it all out for me. How do you name your SPs?
I like how their tables are tagged with a prefix so you can sort of tell its functionality, purpose, and relationship with other tables right off the bat
That is why you have Schemas in SQL Server, you create a schema to group several object together and then you can give the HR person just access to the HR schema
Prefixing all stored procedures with USP_ or SP_ seems redundant and anti-beneficial as the object explorer already sorts it all out for me. How do you name your SPs?
SP_ should never be use because you will get a performance hit, whenever SQL server 'sees' a proc that starts with sp_ it will check the master database first, worst if MS decided to ship a proc with the sane name as yours and it starts with sp_ yours will never get executed
BTW not everyone is using the project explorer, some people like to do this in T-SQL
I personally will prefix my stored procedures with a unique name the describes what it does. For example.
SelectUserAccountById
or
InsertUserAccount
Typically the table name is referenced in the name, in the example above, the table would be UserAccount.
I do not prefix my stored procedures with SP or anything similar UNLESS I am building an extension that goes into a framework such as DotNetNuke, then I use a prefix for my company name.
I find it useful to name the strored proc as
TableName_Action
example RefClient_Insert, RefClient_Search, RefEmployee_Delete
This way, since the tables are grouped (Ref = Reference in this case) the SPs are grouped too.
Note that I have used _ just for clarity, you may skip it if you like.
I started naming all of the SQL objects with a widget type prefix. For example...
Photo Gallery Database Objects (abbreviated list)
Old Name | New Name
-------------------------------------------------
tblCategories | tblPGCategories
tblItems | tblPGItems
spGetCategories | spPGGetCategories
spUpdateCategory | spPGUpdateCategory
spGetItems | spPGGetItems
spUpdateItem | spPGUpdateItems
Event Calendar Database Objects (abbreviated list)
Old Name | New Name
-------------------------------------------------
tblCategories | tblECCategories
tblItems | tblECItems
spGetCategories | spECGetCategories
spUpdateCategory | spECUpdateCategory
spGetItems | spECGetItems
spUpdateItem | spECUpdateItems
We developed lots of websites and when a customer wanted a piece of functionalty we thought we could sell to others we would create it as a widget. We would then market these widgets to other customers.
This worked great until we started adding widgets we developed from other websites. We wound up with duplicate names for some of our code. So, out of necessity we implement a widget type naming convention. This made it very easy to integrate all the widgets we created.