Integrate with CCK

My first concern is that it must reliable and self contained.

Having dependencies on other contrib modules would complex the structure, installation and maintenance.
Having all the features in my hands, give me a lot of flexibility in terms of functions and features.

You can use CCK with it. You can also remove or rename the fields I added in my content types through template functions
or custom code.

Views support is under development.

Thanks, Roberto.

I vote for independence from CCK, Views, all contrib modules. I am looking at Storm for Drupal Web development and upgrade projects. Storm would not be of use if I had to wait for Storm upgrades for the length of time required to get CCK ready for Drupal 6. I agree with making contrib modules available to extend Storm but disagree with making Storm dependent on those modules.

Indepence is good if you look at upgrading time. But CCK would give admins more control in an easier way!

CCK support has my +111

Cheers

No, sorry.

I'd like to reopen this one.

Not necessarily saying it will go any further than it has before, but so that it can be reconsidered at least!

Good stuff! There is hope :)
The lack of CCK support has made me decide not to use STORM for now so I will keep checking back here!

Thanx!

i agree with this. While it is great to have a self sustained module, my site is based on views, panels, cck, tokens, and location.

Being able to leverage Storm and it's core assets into those modules would be great.

Thanks for the module. Still evaluating it for my needs.

Here are my use cases/needs.

I would love to geo-code the organizations or use cck to pre-fill those values.

I am trying to create a bug system much like CaseTracker. I would like to assign the project that someone can submit a bug to so everyone does not get to see all the projects. also, I do not need all the pricing and other info on a ticket. I would also like to set a default value for severity.

I also want to allow groups to create their own projects so I could allow a group to create a project using Storm. The user interface is killer for that. But I am not quite sure how to manage the multiple users creating projects.

Chris

Yes, CCK support would be great to have for STORM.

+1 for CCK use.

I believe it's one of the design goals of Drupal to re-use as much as possible. IMHO CCK should be used for the fields in storm content types, even if that means dependence on the date.module for example for some fields.

A small example of what could be possible is that if one did use CCK date fields for certain items they could be easily displayed using the calendar.module if required. Without this one would have to re-invent specific views integration, etc. I notice revisions of Storm types are not working at the moment - perhaps something else that core re-use would do for the project?

Given the great work that's already been done though, I would imagine it's probably best to get the workflow and mechanisms for the basic Storm system working perfectly first and concentrate on integration with CCK as part of a later version.

One of the thoughts of the original author was that he didn't want required dependencies on other contrib modules. My own views are to avoid them where possible, but I think that we may end up needing some, so am not totally ruling it out.

With regards to CCK, there is a big opportunity with Fields in Core for D7. Therefore, my plan is that to work on other areas of Storm at the moment, and when it gets to the point to port (after all - code freeze for D7 is on Sep 1st - that will be here before too long) to probably move over. Probably!

I vote for the D7 path. During the D4 to D5 conversion, I had to rewrite several custom modules to remove dependency on non core modules that were not upgraded during the time I was upgrading. The D5 to D6 upgrade did not produce the same problem for my modules because they were dependent only on core modules but I did have upgrade problems for some of the other non core modules used on some of my sites because those modules were dependent on modules that were non core. The "can use but is not dependent on" approach works well for non core modules including CCK and Views.

Perhaps there is a convenient way to do both?

For example - Storm can work as it is "out of the box", but there could be a simple admin settings page (per content type?) which allows user to reassign the built in fields with CCK fields.

So, this would allow for the Date API to be used for date fields, the Node Reference and User Reference could be used for Project/People references, etc...

While I applaud the concept of keeping this suite of modules as independent as possible, I think its shortsighted to not reuse high quality code. Lets be real here - CCK is not a "fringe" module set and relying on CCK/Views to add functionality can improve the UI, reduce code bloat AND open the doors for additional integration without specific rewrites.

I am currently investigating STORM for my own dev company, but I am somewhat tempted to reinvent the wheel with "stock" (cck/views/rules) modules. While I appreciate what STORM can do, I also think its possible to use some bread'n'butter modules to make it better.

Ron

I do agree that CCK will help Storm - but surely including an optional dependency will bloat the code even more - as this would be a major change to the structure and storage of fields?

CCK (fields) will be in core from D7, which means not only that everyone with D7 will have it, but will mean that the APIs are static for the duration of D7. This provides a much easier way to implement this.

Please do report back about your decision for your company - and how it turned out though. It is extremely useful to have feedback once you've been using whichever system you choose for a while.

It is very easy, and tempting, to make storm very dependent on huge number of other modules (cck, views, mailhandler, date, calendar, support, charts, popups, fileframework, rules... - to name a few that I would like to see integrated) which are very useful and nice modules - but joggling with all of them (and their dependencies) would be horror to maintain and hustle to install and use. And I believe that is why Roberto started this without dependencies, and why Magnity wants it to stay that way - and why I support their choice.

For simple example you can review thread #315455: Date API for Project and Task Dates where only adding small support for date_api and calendar showed one bug in date_popup and other in calendar, and mine time spent on locating problem wasn't

On the other side, a would like to see a project, separate from storm, that is using other modules - for the start it would be nice to, only, replicate storm functionality. That would leave a choice for everyone - me included. But user base and number of devs are not big enough to have two separate projects.

btw. Since CCK will be in core drupal 7, that probable wouldn't be considered as external dependency.

I reviewed this module several few months ago. It was close, but I wasn't comfortable with a strategic commitment because of lack of CCK and Views integration.

Since then, #320801: Expose Storm fields to Views has happened, and that is great.

Reusing high quality CCK code reduces bugs, increases flexibility, and allows more developer time for functionality enhancement because of less "reinventing the wheel" coding.

In terms of strategic commitment, I can confirm that Storm will change over to use Fields in Core for the D7 version.

Maybe that message isn't clear enough above.

Currently awaiting: #510742: Port Storm to Drupal 7 (Now called Project Management)

It seems silly to have this issue open. For the port to D7, I am using Fields in Core functionality, and it is being done as part of the port, so the only issue that matter is #510742: Port Storm to Drupal 7 (Now called Project Management).