Looks very promising, but I think it needs some first steps documentation so that people know how to set up for testing.

Do you work with field formatters on this? Therefore you don't need database storage. I would try to prevent additional database calls for formatting purposes. That could be detrimental to bigger websites and its performance optimizing with bigger modules running.

if you need a co-developer, let meknow ...
kind regards and good luck!

Comments

dqd’s picture

dqd
(formerly "diqidoq")
CreditAttribution: dqd commented

EDIT: Sorry, now I took a deeper look into it. It works with extensible presets, so database storage is needed, no doubt.

The whole story is that I have started a similar project a week ago for my needs.
It was a collection of field formatters rendered into a module with admin options to change some parts of the formatters. Close to this here but this one here seems to be a step further and much more transparent for users, so let me try it out.

I try to expand text field usage with it now for links, title tagging (h2,h1,etc) and script implementation for pictures and fancybox or similar.

I will report next days.

rjay’s picture

rjay CreditAttribution: rjay commented
Assigned: Unassigned » rjay

I'm not sure if you noticed but we also have a Drupal 6 version of this module, Semantic CCK, which uses CCK hooks to save it's settings along with the rest of the CCK field settings, and therefore not requiring it's own database table as you suggested.

However, for Drupal 7 my co-maintainer (rhache) and I decided we wanted to try to use presets so that Semantic Fields would no longer be doubling the length of the field editing form (as Semantic CCK does in Drupal 6). As you correctly figured out, this does require a separate database table to store the settings for each preset. I wanted to try to avoid introducing an extra database table myself as well, but it became a necessary trade-off when moving to using presets for D7.

We have not tried to do anything with field formatters so far, because the main purpose of this module is to give the ability to create semantically rich markup around the field values, not to modify the values themselves. Formatting of field values is typically handled by the module that implements that particular field type. Also, there is already at least one module that I know of that allows you to create your own field formatters: Custom Formatters.

I will try to create some simple documentation for testers soon. Thanks for the interest in this module. Feel free to post any other feature requests you may come up with as you continue to test this module.

- Ryan

dqd’s picture

dqd
(formerly "diqidoq")
CreditAttribution: dqd commented

I wanted to try to avoid introducing an extra database table myself as well, but it became a necessary trade-off when moving to using presets for D7.

I absolutely agree with the presets, much better this way.

the main purpose of this module is to give the ability to create semantically rich markup around the field values, not to modify the values themselves. Formatting of field values is typically handled by the module that implements that particular field type

The name Field formatters may confuse a little bit. Of course it can change the values by validating php to it like Custom Formatters does, but field formatter functions of D7 can also handle the complete output style. In many cases the way you would like to do it with Semantic fields is too "rigid". If you would ask me, for me Semantic fields is the first step in the right direction but it should co-operate with some field formatting functions to make it able to modify the complete surrounding html, so that the Drupal administrator could add javascript behaviour controls, nesting container-groups, hidden fields and many many more without coding in the sites/all folder. (the options are endless then)

By the way, I found this module here just because I was looking if somebody did what I planned to do :-) Thats maybe why I have such a clear picture of what it could be *ggg* sorry if I push it too hard.

kind regards from Berlin (and let me know if I can do anything)

rjay’s picture

rjay CreditAttribution: rjay commented
Status: Active » Closed (fixed)

field formatter functions of D7 can also handle the complete output style

Can you provide an example of a field formatter that handles the complete HTML markup for a field? I wasn't aware that they do in D7 but if that's true then I'd like to take a closer look at how that is being done.

Anyways, I've just added a section on usage to the project page so users will have a better idea of how to work with Semantic Fields. Marking this issue as closed, since that was the original task.

dqd’s picture

dqd
(formerly "diqidoq")
CreditAttribution: dqd commented

For some hard to explain reasons I had to jump back to views, so I sadly can't give a lot input in the moment here. Sorry for that. My first intension was, I wanted to keep my d7 install as clean as possible and didn't wanted to have a too much overblown module list running. So been sad, field formatting and semantic fields is still very interesting for those who try to figure out using drupal without views, panels and ctools modules running for showing content in different ways. But I had to cut the timespace here. Sadly there are customer requests which are still too hard to realize without views. So I am back on the D6 ways doing it in D7. While running views field formatting and semantic fields kind of tasks are widly implentented in views.

Of course there ist still a chance of making it meaningful together. I think comparing them deeply and looking for where one can jump in for the other would make it useful parallel. Semantic fields may could be a better central point to change all over the side same looking output of titles, footnotes, certain paragraphs etc. in general, so you don't need to change it on every view edit point again and again by checking the checkbox "standart field output". But I don't know if the "standart field output" also registers the changes in Semantic Fields? Maybe this should be pointed out in Info text or documentation?

kind regards