I'm looking for a strategy for managing links within articles. The body of the article is saved in a database and pulled during page assembly. What all should be saved in the database to easily define and manage links?
Some purists believe that markup should NEVER be stored in the database. Some believe its ok in moderation. But to me, the notion of a link is almost inseparable from its html markup.
Is there a better, more succinct way of representing a link in an article (in a database) than simply embedding "anchor text"?
One idea I've kicked around involves embedding just enough markup to semantically describe areas of interest, and in a different table, map those notions to actual URLs. All encounters of a particular notion get wrapped with the link.
<p>Here is an example of a
<span class="external-reference semantic-web">semantic</span>
approach to link management.</p>
A table then might associate the URL of the article and the key class of 'semantic-web' to a URL like http://en.wikipedia.org/wiki/Semantic_Web
<p>Here is an example of a <span class="external-reference semantic-web">
semantic</span>
approach to link management.</p>
Things I like about this approach is that all my URLs are in one location in the database. I could technically change or remove links without touching the body of the article. I have very good class names for CSS.
I don't like having another table to maintain, and another step/phase in render time. It could slow down response time.
Are there any other strategies out there that provide superior link management?
You may want to look at templating (such as Smarty for PHP).
I agree that markup shouldn't normally be held in the database.
However, you might also consider implementing a "pointer" concept, where at each link, you break your storage of the page, add a pointer in the table to the link, then a pointer in the link table to the next segment of content for the page. (I have no idea how complicated that would be - just an idea.)
Or look at how various CMS tools handle the idea. Some just put everything in the database as one big block of text, while others rely on templating, and others may do something else entirely (like object-oriented environments such as Plone).
There are a few attempts to do this that I have seen.
One way to do this is through URL redirects. You can implement a logic component on the server that will interpretate what the URL is requesting rather than a path to the content.
Another attempt is that the links orginally set to a reference value [which can be looked up in a database], and is requested at runtime/generation.
Regardless, you will have to reference the material that you wish to link to with some sort of identifier.
Related
A website I am currently developing with Neos / Flow includes a self-developed shop system implemented as a Flow Plugin. The products, variants and vouchers are kept as domain models.
Since the customer wants to provide their website in different languages I need to find a way to manage translations for the domain objects.
I cannot find a way which is baked into Neos/Flow so my first thought was to simply insert translation identifiers inside the translatable fields (description & stuff like that) which are then used inside the view with the translation viewhelper. This would work totally fine if the customer would not want to edit those fields by themselves.
My next idea was to just implement an extra field for each language-dimension and each translatable field (like description_en; description_es, …). But this would be the worst approach in terms of maintainability and changeability.
I usually worked on TYPO3 projects where translation of domain objects is really easy and working out of the box. So this experience inside Neos is very frustrating.
Does anybody came across a similar problem or even has found a solution to this?
whenever we've got the requirement to have multi-language content so far, we've solved that, by storing the data within the Neos Content Repository. This way language handling aka dimensions work out of the box. Also, building a UI for that records is very easy by using inline editing or the inspector of the content module.
Note, that storing data in the CR does not necessarily means, that you have to store it under the /site root node. You could also add a new root node /products to store your products.
You could have a look at https://github.com/neos/metadata-contentrepositoryadapter where meta data is stored under its own root.
Hope that helps,
Cheers, Daniel
For the record, something like that could also be achieved with the Doctrine Translateable extension in pure Flow:
https://github.com/Atlantic18/DoctrineExtensions/blob/master/doc/translatable.md
See http://flowframework.readthedocs.io/en/stable/TheDefinitiveGuide/PartIII/Persistence.html#on-the-doctrine-event-system on how to activate the extension in Flow.
However, the cleaner aproach indeed is to actually separate domain model and content (unless you build a CMS and the content is your domain ;)
I have an ASP.NET MVC3 application which has multilingual support. Almost every word has multilingual support and at each page request I get all the words in the currently selected language from the database into a List and I use it for each Word: I hold MeaningID for each element and print out the matched one from the List. Costly approach, but better than reaching to database for every Word.
Still, I wonder if there's a data structure I can use globally throughout the project, which is only loaded from the database when the user changes the selected language. Is there a session like list structure can I use for such a purpose?
EDIT: To make things clearer I'm posting my database tables.
--Word-- --WordBase-- --Language--
ID ID ID
Text Text Name
BaseID
LanguageID
As it's seen, WordBases are meanings that Words depend on by a Language. Example data is:
--Word-- --Base-- --Language--
1;Hallo;1;1 1;Hello 1-Deutsch
2;Hello;1;2 2;Good 2-English
3;Gut; 2;1
4;Good; 2;2
Your web app is like a dictionary? I mean... your "words" are the data of your application... or are you talking about internationalization?
If it is internationalization, I think there are better ways to do it... using the tools built in. Check this: http://afana.me/post/aspnet-mvc-internationalization.aspx
If the translatable data is too large... may be you could have an hybrid approach... keeping tokens in database... and translation in resource files. Then, caching would be useful, specially if your data doesn't change very often (you can set caching for 30min... and for that time you avoid SQL queries to retrieve words in every request).
You should cache this using Cache. Then, you can manage the Cache to hold the information during the user session or by time expiration.
Take a look here: Walkthrough: Caching Application Data in ASP.NET.
I'm about to start coding a website, and because this is my first time writing a code for a webpage, there is something I've been wondering about.
Writing separate header.php and footer.php is probably the fastest and easiet way to do stuff.
The problem is, what if for some pages I'd like to use specific javascript files and codes and for some I would like to use others?
It would result in more HTTP request and will eventually impact the performance of the site.
I thought about using if statements in the header and just give every page exactly what it needs, and nothing more.
But which way is more efficient?:
Coding global header.php and footer.php files and separating the codes using if statements OR add the whole header+footer code to every single file (ie local header/footer)?
P.S global and local header/footer is something I just made up, didn't really know how to call it, lol.
The advantage of your "global" header and footer is that 1) they are consistent and changes are "global" and 2) they are included in the pages in server code. So there isn't a lot of HTTP traffic if you do the include on the server side.
You can (and should) do page-specific includes on the server side if at all possible using logic that determines what to load at the time of the Request.
There are other ways to accomplish this but with straight up PHP, what you are considering is the best way.
If you are using a framework like Yii, you can do this sort of thing in layouts but with simple PHP, you are on the right track.
Defining the header and footer in each page (local), causes you to repeat a lot of code and causes maintenance headaches going forward. You have a lot of pages to update for simple header/footer changes.
I want to employ CakePHP's basic caching functionality on my site's home page. However, there is one element on the page that should display different data depending on the visitor's location, as determined by their IP address.
You can't wrap <cake:nocache> around variables that are set in the controller, which is where I was previously determining the location and getting the data. My question therefore is: where can I optimally set a (session?) variable to contain visitor location information before the controller? How can I use this information to populate an array of data for the nocached portion of the view, while completely sidestepping the controller action, which is no longer being called?
Any advice greatly appreciated!
Hmm, well, apparently CakePHP questions aren't of much interest to the world at large: only 8 views in 2 days :(
In any case I investigated a bit further and discovered that, while the <nocache> tags don't let you surround variables to make them dynamic, they DO allow you to make non-caching calls to elements or helpers. I therefore extracted the relevant part of my page into an element, and populated the data array by calling a helper function.
This did mean that I had to access the model from inside the helper with
$this->Modelname =& ClassRegistry::init("Modelname");
and I'm not sure this is necessarily the respectful CakePHP and/or MVC way of doing things, but at least it's some way towards a solution!
Based on the following example URL structure:
mysite.com/mypage.aspx?a=red&b=green&c=blue
Pages in the application use ASP.net user controls and some of these controls build a query string. To prevent duplicate keys being created e.g. &pid=12&pid=10, I am researching methods of rewriting the URL:
a)
mysite.com/mypage.aspx/red/green/blue
b)
mysite.com/mypage.aspx?controlname=a,red|b,green|c,blue
Pages using this structure would be publishing content that I would like to get indexed and ranked - articles and products (8,000 products to start, with thousands more being added later)
My gut instinct tells me to go with the first method, but would it would be overkill to add all that infrastructure if the second method will accomplish my goal of getting pages indexed AND ranked.
So my question, looking at the pro's and con's, Google Ranking, time to implement etc. which method should I use?
Thanks!
From an SEO perspective you want to try and avoid the querystring, so getting it into the URL and a short form URL is going to get you a better "bang for the buck" on the implementation side of things.
Therefore, I'd recommend the first.
Why don't use MVC pattern, this way all your link will be SEO ready. Check here, you will find what is MVC and also some implementation in .net!
You can easily make SEO-friendly URLs with the help of Helicon Ape (the software which allows having basic Apache functionality on your IIS server). You'll need mod_rewrite I guess.
If you get interested, I can help you with the rules.
Can you explain in more detail your current architecture and what the parameters all mean? There's nothing really wrong with query strings if it's truly dynamic content. Rewriting ?a=red&b=green&c=blue to /red/green/blue is kinda pointless and it's unclear from the URL what might be on the page.
The key is to simplify as much as possible. Split the site into categories and give each "entity" one URL.
For example, if you are selling products, use one URL per product, with keywords in the URL - e.g. mysite.com/products/red-widget or mysite.com/products/12-red-widget if you need the product ID.